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

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

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

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

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

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

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

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

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

1.1 दस्तावेज़ का स्ट्रक्चर

1.1.1. डिवाइस के टाइप के हिसाब से ज़रूरी शर्तें

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

दूसरी सभी ज़रूरी शर्तें, जो सभी Android डिवाइस पर लागू होती हैं उन्हें सेक्शन 2 के बाद वाले सेक्शन में बताया गया है. इस दस्तावेज़ में इन ज़रूरी शर्तों को "मुख्य शर्तें" कहा गया है.

1.1.2. ज़रूरत आईडी

ज़रूरी आईडी असाइन किया गया है.

  • आईडी सिर्फ़ ज़रूरी शर्तों के लिए असाइन किया गया है.
  • 'सुझाई गई ज़रूरी शर्तें', [SR] के रूप में मार्क की जाती हैं, लेकिन आईडी असाइन नहीं की गई है.
  • आईडी में : डिवाइस टाइप आईडी - शर्त का आईडी - ज़रूरी आईडी (उदाहरण के लिए, C-0-1) शामिल होता है.

हर आईडी के बारे में यहां बताया गया है:

  • डिवाइस टाइप आईडी (2. डिवाइस के टाइप)
    • C: मुख्य (ज़रूरी शर्तें)
    • H: Android हैंडहेल्ड डिवाइस
    • T: Android टेलीविज़न डिवाइस
    • जवाब: Android Automotive लागू करना
    • Tab: Android टैबलेट को लागू करना
  • शर्त का आईडी
    • जब कोई शर्त पूरी नहीं होती, तब इस आईडी की वैल्यू 0 के तौर पर सेट होती है.
    • अगर किसी शर्त के तहत कोई शर्त लागू होती है, तो पहली शर्त के लिए 1 असाइन किया जाता है और उसी सेक्शन और उसी तरह के डिवाइस में नंबर में 1 की बढ़ोतरी हो जाती है.
  • ज़रूरी शर्त का आईडी
    • यह आईडी 1 से शुरू होता है और उसी सेक्शन और उसी शर्त में 1 की बढ़ोतरी होती है.

1.1.3. सेक्शन 2 में ज़रूरी आईडी

सेक्शन 2 में मौजूद ज़रूरी शर्त का आईडी, उस सेक्शन आईडी से शुरू होता है जिसके बाद, ऊपर बताया गया ज़रूरी आईडी होता है.

  • सेक्शन 2 के आईडी में ये शामिल हैं : सेक्शन आईडी / डिवाइस टाइप आईडी - शर्त का आईडी - ज़रूरी आईडी (उदाहरण के लिए, 7.4.3/A-0-1).

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

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

इस सेक्शन में, अलग-अलग तरह के डिवाइसों के बारे में जानकारी दी गई है. साथ ही, हर तरह के डिवाइस पर लागू होने वाली अन्य ज़रूरी शर्तों और सुझावों के बारे में भी बताया गया है.

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

2.1 डिवाइस कॉन्फ़िगरेशन

डिवाइस टाइप के हिसाब से हार्डवेयर कॉन्फ़िगरेशन में बड़े अंतर जानने के लिए, इस सेक्शन में दी गई डिवाइस से जुड़ी ज़रूरी शर्तें देखें.

2.2. हैंडहेल्ड की ज़रूरतें

Android हैंडहेल्ड डिवाइस का मतलब ऐसे Android डिवाइस से है जिसे आम तौर पर हाथ में पकड़कर इस्तेमाल किया जाता है, जैसे कि mp3 प्लेयर, फ़ोन या टैबलेट.

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

  • उनमें ऐसी पावर सोर्स हो जो हिलने-डुलने में मदद करता हो, जैसे कि बैटरी.
  • फ़ोन की स्क्रीन का साइज़ 2.5 से 8 इंच के बीच होना चाहिए.

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

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

2.2.1. हार्डवेयर

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

  • [7.1.1.1/H-0-1] फ़ोन की स्क्रीन, डायगनल साइज़ की होनी चाहिए और यह कम से कम 2.5 इंच की होनी चाहिए.
  • [7.1.1.3/H-SR] लोगों को डिसप्ले साइज़ बदलने की सुविधा देने के लिए, इस बात का बहुत ज़्यादा सुझाव दिया जाता है.(स्क्रीन की डेंसिटी)

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

  • [7.1.4.5/H-1-1] EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, और VK_EXT_hdr_metadata एक्सटेंशन के लिए, सहायता देना ज़रूरी है.

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

  • [7.1.5/H-0-1] लेगसी ऐप्लिकेशन के साथ काम करने वाले मोड के साथ काम करना ज़रूरी है, जैसा कि अपस्ट्रीम Android ओपन सोर्स कोड लागू किया गया है. इसका मतलब है कि जिन डिवाइसों पर यह सुविधा काम करती है उन पर ट्रिगर या थ्रेशोल्ड में बदलाव नहीं करना चाहिए. साथ ही, काम करने वाले मोड के काम करने के तरीके में भी कोई बदलाव नहीं करना चाहिए.
  • [7.2.1/H-0-1] तीसरे पक्ष के इनपुट के तरीके के एडिटर (IME) ऐप्लिकेशन के साथ काम करना ज़रूरी है.
  • [7.2.3/H-0-1] होम, हाल ही के, और वापस जाएं फ़ंक्शन देना ज़रूरी है.
  • [7.2.3/H-0-2] बैक फ़ंक्शन (KEYCODE_BACK) को दबाकर रखने वाले सामान्य और देर तक इवेंट, दोनों को फ़ोरग्राउंड ऐप्लिकेशन में भेजना ज़रूरी है. इन इवेंट को सिस्टम के ज़रिए इस्तेमाल नहीं करना चाहिए और इन्हें Android डिवाइस के बाहर (उदाहरण के लिए, Android डिवाइस से कनेक्ट किया गया बाहरी हार्डवेयर कीबोर्ड) से ट्रिगर किया जा सकता है.
  • [7.2.4/H-0-1] टचस्क्रीन इनपुट पर काम करना ज़रूरी है.
  • [7.2.4/H-SR] उपयोगकर्ता के चुने गए सहायक ऐप्लिकेशन को लॉन्च करने का सुझाव दिया जाता है. दूसरे शब्दों में, यह सुझाव दिया जाता है कि वह ऐप्लिकेशन जो Voiceइंटरैक्शनService को लागू करता है या अगर फ़ोरग्राउंड की गतिविधि से, ज़्यादा देर तक दबाए गए इवेंट में मौजूद कोई इवेंट नहीं हो पाता है, तो KEYCODE_MEDIA_PLAY_PAUSE या KEYCODE_HEADSETHOOK को देर तक दबाकर रखने वाली गतिविधि ACTION_ASSIST को मैनेज करती है.
  • [7.3.1/H-SR] तीन-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

  • [7.3.1/H-1-1] कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.

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

  • [7.3.4/H-1-1] कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.

हैंडहेल्ड डिवाइस के इस्तेमाल से वॉइस कॉल करने की सुविधा मिलती है. साथ ही, getPhoneType में PHONE_TYPE_NONE के अलावा कोई भी अन्य वैल्यू दिखाई जा सकती है:

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

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

  • [7.3.12/H-SR] का सुझाव दिया जाता है कि 6 डिग्री फ़्रीडम वाले पोज़ सेंसर के साथ काम करें.
  • [7.4.3/H] इसमें Bluetooth और Bluetooth LE के साथ काम करने की सुविधा शामिल होनी चाहिए.

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

  • [7.4.7/H-1-1] डेटा बचाने की सेटिंग वाला मोड उपलब्ध कराना ज़रूरी है.

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

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

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

  • [7.6.1/H-1-1] अगर डिफ़ॉल्ट डिसप्ले, qHD (जैसे FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 416 एमबी होनी चाहिए.

  • [7.6.1/H-2-1] अगर डिफ़ॉल्ट डिसप्ले, HD+ (जैसे कि HD, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 592 एमबी होनी चाहिए.

  • [7.6.1/H-3-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (जैसे कि WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 896 एमबी होनी चाहिए.

  • [7.6.1/H-4-1] अगर डिफ़ॉल्ट डिसप्ले क्यूएचडी (जैसे कि QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1344 एमबी होनी चाहिए.

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

  • [7.6.1/H-5-1] अगर डिफ़ॉल्ट डिसप्ले, qHD (जैसे FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 816 एमबी होनी चाहिए.

  • [7.6.1/H-6-1] अगर डिफ़ॉल्ट डिसप्ले, HD+ (जैसे कि HD, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 944 एमबी होनी चाहिए.

  • [7.6.1/H-7-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (जैसे कि WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए.

  • [7.6.1/H-8-1] अगर डिफ़ॉल्ट डिसप्ले क्यूएचडी (जैसे कि QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1824 एमबी होनी चाहिए.

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

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

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

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

  • [7.6.1/H-10-1] ऐप्लिकेशन के निजी डेटा (यानी "/data" पार्टीशन) के लिए, कम से कम 4 जीबी का स्टोरेज खाली होना चाहिए.
  • फ़ीचर फ़्लैग android.hardware.ram.normal का एलान करना चाहिए.

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

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

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

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

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

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

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

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

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

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

  • [5.1.1/H-0-1] एएमआर-एनबी
  • [5.1.1/H-0-2] एएमआर-डब्ल्यूबी
  • [5.1.1/H-0-3] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
  • [5.1.1/H-0-4] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [5.1.1/H-0-5] AAC ELD (कम देरी वाले AAC)

हैंडहेल्ड डिवाइस को लागू करने के लिए, नीचे दिए गए ऑडियो डिकोड करने की सुविधा काम करनी चाहिए:

  • [5.1.2/H-0-1] एएमआर-एनबी
  • [5.1.2/H-0-2] एएमआर-डब्ल्यूबी

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

  • [5.2/H-0-1] H.264 एवीसी
  • [5.2/H-0-2] VP8

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

  • [5.3/H-0-1] H.264 एवीसी
  • [5.3/H-0-2] H.265 एचईवीसी
  • [5.3/H-0-3] MPEG-4 SP
  • [5.3/H-0-4] VP8
  • [5.3/H-0-5] VP9

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

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

  • [3.2.3.1/H-0-1] एक ऐसा ऐप्लिकेशन होना चाहिए जो SDK दस्तावेज़ों में बताए गए ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT इंटेंट को मैनेज करे. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ देने वाले का डेटा ऐक्सेस करने की अनुमति दें.
  • [3.4.1/H-0-1] android.webkit.Webview एपीआई को पूरी तरह लागू करना ज़रूरी है.
  • [3.4.2/H-0-1] सामान्य उपयोगकर्ता की वेब ब्राउज़िंग के लिए, स्टैंडअलोन ब्राउज़र ऐप्लिकेशन होना ज़रूरी है.
  • [3.8.1/H-SR] ऐसा डिफ़ॉल्ट लॉन्चर लागू करने का सुझाव दिया जाता है जिसमें शॉर्टकट, विजेट, और विजेट की सुविधाओं को ऐप्लिकेशन में पिन करने की सुविधा काम करती है.
  • [3.8.1/H-SR] डिफ़ॉल्ट लॉन्चर लागू करने का सुझाव दिया जाता है. यह लॉन्चर, ShortcutManager एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन से मिलने वाले दूसरे शॉर्टकट का क्विक ऐक्सेस देता है.
  • [3.8.1/H-SR] हमारा सुझाव है कि इसमें ऐप्लिकेशन आइकॉन के लिए बैज दिखाने वाला डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल करें.
  • [3.8.2/H-SR] का इस्तेमाल करने का सुझाव दिया जाता है, ताकि तीसरे पक्ष के ऐप्लिकेशन विजेट के साथ काम किया जा सके.
  • [3.8.3/H-0-1] तीसरे पक्ष के ऐप्लिकेशन को Notification और NotificationManager एपीआई क्लास का इस्तेमाल करके, लोगों को अहम इवेंट की सूचना देने की अनुमति देनी होगी.
  • [3.8.3/H-0-2] ज़रूरी सूचनाएं दिखाने की सुविधा होनी चाहिए.
  • [3.8.3/H-0-3] चेतावनी देने की सुविधा काम करनी चाहिए.
  • [3.8.3/H-0-4] एक नोटिफ़िकेशन शेड शामिल करना ज़रूरी है, जिससे उपयोगकर्ता को उपयोगकर्ता की सुविधा के ज़रिए, सूचनाओं को सीधे तौर पर कंट्रोल करने (उदाहरण के लिए, जवाब देने, स्नूज़ करने, खारिज करने, ब्लॉक करने) करने की सुविधा मिले. जैसे, ऐक्शन बटन या एओएसपी में लागू किए गए कंट्रोल पैनल.
  • [3.8.3/H-0-5] RemoteInput.Builder setChoices() के ज़रिए दिए गए विकल्पों को नोटिफ़िकेशन शेड में दिखाना ज़रूरी है.
  • [3.8.3/H-SR] RemoteInput.Builder setChoices() के ज़रिए सूचना शेड में दिए गए पहले विकल्प को दिखाने का सुझाव दिया जाता है. यह विकल्प, उपयोगकर्ता के किसी अन्य इंटरैक्शन के बिना ही दिया जाता है.
  • [3.8.3/H-SR] जब उपयोगकर्ता नोटिफ़िकेशन शेड में सभी सूचनाओं को बड़ा करता है, तब आपको RemoteInput.Builder setChoices() में दिए गए सभी विकल्पों को नोटिफ़िकेशन शेड में दिखाने का सुझाव दिया जाता है.
  • [3.8.4/H-SR] सहायक कार्रवाई को मैनेज करने के लिए, डिवाइस पर Assistant को लागू करने का सुझाव दिया जाता है.

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

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

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

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

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

  • [3.9/H-1-1] Android SDK के दस्तावेज़ में दी गई, डिवाइस एडमिन की सभी नीतियों को लागू करना ज़रूरी है.
  • [3.9/H-1-2] android.software.managed_users सुविधा फ़्लैग का इस्तेमाल करके, मैनेज की जा रही प्रोफ़ाइल पर काम करने का एलान करना ज़रूरी है. हालांकि, ऐसा तब नहीं होगा, जब डिवाइस को कॉन्फ़िगर किया गया हो, ताकि वह कम रैम वाले डिवाइस के तौर पर रिपोर्ट करे. इसके अलावा, संगठन के स्टोरेज को शेयर किए गए स्टोरेज के तौर पर रखे, ताकि इसे हटाया न जा सके.

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

  • [3.10/H-0-1] तीसरे पक्ष की सुलभता सेवाओं के साथ काम करना ज़रूरी है.
  • [3.10/H-SR] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड किया जाए. इसके लिए, स्विच ऐक्सेस और TalkBack (पहले से इंस्टॉल किए गए लिखाई को बोली में बदलने वाला इंजन पर काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं की तुलना या उससे ज़्यादा सुविधाएं दी जानी चाहिए. ये सुविधाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में दी गई हैं.
  • [3.11/H-0-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा दी जानी चाहिए.
  • [3.11/H-SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि डिवाइस पर उपलब्ध भाषाओं में काम करने वाले टीटीएस इंजन को शामिल किया जा सके.
  • [3.13/H-SR] 'क्विक सेटिंग' यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को शामिल करने के लिए, इसका सुझाव दिया जाता है.

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

  • [3.16/H-1-1] साथी डिवाइस से जोड़ने की सुविधा के साथ काम करना ज़रूरी है.

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

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

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

  • [8.2/H-0-1] यह पक्का करना ज़रूरी है कि क्रम में लिखा गया डेटा, कम से कम 5 एमबी/सेकंड हो.
  • [8.2/H-0-2] यह पक्का करना ज़रूरी है कि रिकॉर्ड किए गए डेटा की परफ़ॉर्मेंस, कम से कम 0.5 एमबी हो और इसमें किसी भी क्रम में हो.
  • [8.2/H-0-3] यह पक्का करना ज़रूरी है कि क्रम में कम से कम 15 एमबी/सेकंड की परफ़ॉर्मेंस हो.
  • [8.2/H-0-4] कम से कम 3.5 एमबी/सेकंड का रैंडम रीड परफ़ॉर्मेंस पक्का करना ज़रूरी है.

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

  • [8.3/H-1-1] बैटरी सेवर की सुविधा को चालू और बंद करने के लिए, लोगों को ज़रूरी अधिकार देना ज़रूरी है.
  • [8.3/H-1-2] लोगों को उन सभी ऐप्लिकेशन को दिखाने का विकल्प देना ज़रूरी है जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी सेव करने वाले मोड से छूट दी गई है.

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

  • [8.4/H-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देना ज़रूरी है. यह प्रोफ़ाइल हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू के बारे में जानकारी देती है. साथ ही, यह जानकारी भी मिलती है कि समय के साथ कॉम्पोनेंट की वजह से बैटरी कितनी तेज़ी से खर्च होती है, जैसा कि Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [8.4/H-0-2] ऊर्जा खपत की सभी वैल्यू, मिलीयंपियर घंटे (mAh) में रिपोर्ट करनी ज़रूरी है.
  • [8.4/H-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल के लागू होने की ज़रूरी शर्तों को पूरा करता है.
  • [8.4/H-0-4] adb shell dumpsys batterystats शेल कमांड के ज़रिए, पावर के इस इस्तेमाल की जानकारी ऐप्लिकेशन डेवलपर को देनी होगी.
  • [8.4/H] अगर किसी ऐप्लिकेशन के लिए हार्डवेयर कॉम्पोनेंट के पावर के इस्तेमाल की जानकारी नहीं दी जा सकती, तो इसे खुद हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.

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

  • [8.4/H-1-1] android.intent.action.POWER_USAGE_SUMMARY इंटेंट का पालन करना ज़रूरी है. साथ ही, पावर के इस इस्तेमाल की जानकारी देने वाला सेटिंग मेन्यू दिखाएं.

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

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

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

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

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

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

Android Television डिवाइस का मतलब Android डिवाइस को लागू करना है. यह दस फ़ीट दूर बैठने वाले उपयोगकर्ताओं के लिए डिजिटल मीडिया, मूवी, गेम, ऐप्लिकेशन, और/या लाइव टीवी का इस्तेमाल करने के लिए एक मनोरंजन इंटरफ़ेस है ("आराम करते हुए" या "10 फ़ुट का यूज़र इंटरफ़ेस").

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

  • डिसप्ले पर रेंडर किए गए यूज़र इंटरफ़ेस को रिमोट तरीके से कंट्रोल करने का तरीका उपलब्ध कराया गया है. यह यूज़र इंटरफ़ेस से दस फ़ीट दूर हो सकता है.
  • इसमें एम्बेड की गई स्क्रीन डिसप्ले है, जिसकी डायगनल लंबाई 24 इंच से ज़्यादा हो या डिसप्ले के लिए VGA, HDMI, DisplayPort या वायरलेस पोर्ट जैसा कोई वीडियो आउटपुट पोर्ट शामिल करें.

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

2.3.1. हार्डवेयर

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

  • [7.2.2/T-0-1] डी-पैड के साथ काम करना ज़रूरी है.
  • [7.2.3/T-0-1] होम और बैक फ़ंक्शन उपलब्ध कराना ज़रूरी है.
  • [7.2.3/T-0-2] बैक फ़ंक्शन (KEYCODE_BACK) को दबाकर रखने वाले सामान्य और देर तक इवेंट, दोनों को फ़ोरग्राउंड ऐप्लिकेशन में भेजना ज़रूरी है.
  • [7.2.6.1/T-0-1] गेम कंट्रोलर के लिए सहायता शामिल करना और android.hardware.gamepad फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
  • [7.2.7/T] रिमोट कंट्रोल की सुविधा दी जानी चाहिए, ताकि उपयोगकर्ता बिना टच वाले नेविगेशन और नेविगेशन बटन के इनपुट ऐक्सेस कर सकें.

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

  • [7.3.4/T-1-1] कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.

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

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

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

  • [7.5.3/T-1-1] ऐसे बाहरी कैमरे के साथ काम करना ज़रूरी है जो इस यूएसबी पोर्ट से कनेक्ट होता हो, लेकिन यह हमेशा कनेक्ट न हो.

अगर टीवी डिवाइस में 32-बिट लागू होता है:

  • [7.6.1/T-1-1] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 896 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
    • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन पर tvdpi या उसके बाद का वर्शन

अगर टीवी डिवाइस पर 64-बिट वाला फ़ॉर्मैट लागू किया जाता है, तो:

  • [7.6.1/T-2-1] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
    • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन पर tvdpi या उसके बाद का वर्शन

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

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

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

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

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

  • [5.1/T-0-1] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [5.1/T-0-3] AAC ELD (कम देरी वाले AAC)

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

  • [5.2/T-0-1] H.264
  • [5.2/T-0-2] VP8

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

  • [5.2.2/T-SR] खास तौर पर सुझाव दिया जाता है कि 30 फ़्रेम प्रति सेकंड पर 720p और 1080p रिज़ॉल्यूशन वाले वीडियो की H.264 एन्कोडिंग पर काम किया जा सके.

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

  • [5.3.3/T-0-1] MPEG-4 एसपी
  • [5.3.4/T-0-2] H.264 एवीसी
  • [5.3.5/T-0-3] H.265 एचईवीसी
  • [5.3.6/T-0-4] VP8
  • [5.3.7/T-0-5] VP9

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

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

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

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

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

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

  • [5.3.5.5/T-2-1] मेन10 लेवल 5 मेन टियर प्रोफ़ाइल के साथ, 60 फ़्रेम प्रति सेकंड की रफ़्तार से यूएचडी डिकोडिंग प्रोफ़ाइल काम करनी चाहिए.

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

  • [5.3.6.4/T-1-1] 60 फ़्रेम प्रति सेकंड की डिकोडिंग प्रोफ़ाइल पर एचडी 1080 पिक्सल

VP9 हार्डवेयर डिकोडर के साथ टेलीविज़न डिवाइस को लागू करने के लिए, सेक्शन 5.3.7 में बताए गए तरीके के मुताबिक VP9 डिकोडिंग का काम करना ज़रूरी है. स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन के हिसाब से इनमें ये शामिल हैं:

  • [5.3.7.4/T-1-1] प्रोफ़ाइल 0 (8 बिट रंग की गहराई) के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल

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

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

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

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

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

  • [5.8/T-1-1] एचडीसीपी 2.2 के साथ काम करना ज़रूरी है.

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

  • [5.8/T-2-1] एचडीसीपी 1.4 वर्शन के साथ काम करना ज़रूरी है

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

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

  • [3/T-0-1] android.software.leanback और android.hardware.type.television सुविधाओं के बारे में बताना ज़रूरी है.
  • [3.4.1/T-0-1] android.webkit.Webview एपीआई को पूरी तरह लागू करना ज़रूरी है.

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

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

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

  • [3.8.14/T-SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि मल्टी-विंडो वाले पिक्चर में पिक्चर (पीआईपी) मोड का इस्तेमाल किया जा सके.
  • [3.10/T-0-1] तीसरे पक्ष की सुलभता सेवाओं के साथ काम करना ज़रूरी है.
  • [3.10/T-SR] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड किया जाए. इसके लिए, स्विच ऐक्सेस और TalkBack (पहले से इंस्टॉल किए गए लिखाई को बोली में बदलने वाला इंजन पर काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं के बराबर या उससे ज़्यादा सुविधाएं दी जानी चाहिए. ये सुविधाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में दी गई हैं.

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

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

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

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

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

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

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

  • [8.3/T-1-1] बैटरी सेवर की सुविधा को चालू और बंद करने के लिए, लोगों को ज़रूरी अधिकार देना ज़रूरी है.
  • [8.3/T-1-2] लोगों को उन सभी ऐप्लिकेशन को दिखाने का विकल्प देना ज़रूरी है जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी सेव करने वाले मोड से छूट दी गई है.

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

  • [8.4/T-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देना ज़रूरी है, जो हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू के बारे में बताता है. साथ ही, यह जानकारी भी देता है कि समय के साथ कॉम्पोनेंट की वजह से बैटरी कितनी तेज़ी से खर्च होती है. इस बारे में Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [8.4/T-0-2] ऊर्जा खपत की सभी वैल्यू, मिलीएम्परे घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
  • [8.4/T-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू बिजली की खपत की रिपोर्ट करना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल के लागू होने की ज़रूरी शर्तों को पूरा करता है.
  • [8.4/T] अगर किसी ऐप्लिकेशन के लिए हार्डवेयर कॉम्पोनेंट पावर के इस्तेमाल की जानकारी नहीं दी जा सकती, तो इसे हार्डवेयर कॉम्पोनेंट में ही एट्रिब्यूट किया जाना चाहिए.
  • [8.4/T-0-4] adb shell dumpsys batterystats शेल कमांड के ज़रिए, पावर के इस इस्तेमाल की जानकारी ऐप्लिकेशन डेवलपर को देनी होगी.

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

Android Watch डिवाइस का मतलब ऐसे Android डिवाइस से है जिसे आम तौर पर कलाई पर पहना जाता है.

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

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

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

2.4.1. हार्डवेयर

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

  • [7.1.1.1/W-0-1] ऐसी स्क्रीन होनी चाहिए जिसका साइज़, 1.1 से 2.5 इंच के बीच हो.

  • [7.2.3/W-0-1] उपयोगकर्ता के लिए Home फ़ंक्शन और वापस जाएं वाले फ़ंक्शन का इस्तेमाल करना ज़रूरी है. ऐसा सिर्फ़ तब होना चाहिए, जब वह UI_MODE_TYPE_WATCH में हो.

  • [7.2.4/W-0-1] टचस्क्रीन इनपुट पर काम करना ज़रूरी है.

  • [7.3.1/W-SR] इस्तेमाल करने का सुझाव दिया जाता है. इसमें तीन-ऐक्सिस एक्सलरोमीटर का इस्तेमाल किया जाता है.

  • [7.4.3/W-0-1] ब्लूटूथ के साथ काम करना ज़रूरी है.

  • [7.6.1/W-0-1] ऐप्लिकेशन के निजी डेटा (यानी "/data" पार्टीशन) के लिए, कम से कम 1 जीबी का स्टोरेज खाली होना चाहिए.

  • [7.6.1/W-0-2] में कर्नेल और यूज़रस्पेस के लिए कम से कम 416 एमबी मेमोरी होनी चाहिए.

  • [7.8.1/W-0-1] माइक्रोफ़ोन होना ज़रूरी है.

  • [7.8.2/W] हो सकता है, लेकिन इसमें ऑडियो आउटपुट नहीं होना चाहिए.

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

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

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

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

  • [3/W-0-1] android.hardware.type.watch सुविधा के बारे में एलान करना ज़रूरी है.
  • [3/W-0-2] uiMode = UI_Mode_TYPE_देखें के साथ काम करना ज़रूरी है.

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

  • [3.8.4/W-SR] हमारा सुझाव है कि सहायक कार्रवाई को मैनेज करने के लिए, डिवाइस पर Assistant को लागू करें.

स्मार्टवॉच के लिए, android.hardware.audio.output फ़ीचर फ़्लैग के बारे में जानकारी देने वाले डिवाइसों को देखें:

  • [3.10/W-1-1] तीसरे पक्ष की सुलभता सेवाओं के साथ काम करना ज़रूरी है.
  • [3.10/W-SR] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड किया जाए. इसके लिए, स्विच ऐक्सेस और TalkBack (पहले से इंस्टॉल किए गए लिखाई को बोली में बदलने वाला इंजन पर काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं की तुलना की जा सकती है या उन्हें इससे ज़्यादा किया जा सकता है. ये सुविधाएं, टॉकबैक ओपन सोर्स प्रोजेक्ट में दी गई हैं.

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

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

  • [3.11/W-0-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा दी जानी चाहिए.

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

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

  • [8.3/W-SR] लोगों को ऐसे सभी ऐप्लिकेशन दिखाने का सुझाव दिया जाता है जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड से छूट दी गई है.
  • [8.3/W-SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि बैटरी सेवर की सुविधा को चालू और बंद करने के लिए, उपयोगकर्ता को सुविधाएं दी जा सकें.

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

  • [8.4/W-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देना ज़रूरी है. यह प्रोफ़ाइल हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू के बारे में जानकारी देती है. साथ ही, यह जानकारी भी मिलती है कि समय के साथ कॉम्पोनेंट की वजह से बैटरी कितनी तेज़ी से खर्च होती है, जैसा कि Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [8.4/W-0-2] ऊर्जा खपत की सभी वैल्यू, मिलीयंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
  • [8.4/W-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल के लागू होने की ज़रूरी शर्तों को पूरा करता है.
  • [8.4/W-0-4] adb shell dumpsys batterystats शेल कमांड के ज़रिए, पावर के इस इस्तेमाल की जानकारी ऐप्लिकेशन डेवलपर को देनी होगी.
  • [8.4/W] अगर किसी ऐप्लिकेशन के लिए हार्डवेयर कॉम्पोनेंट पावर के इस्तेमाल की जानकारी नहीं दी जा सकती, तो इसे खुद हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.

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

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

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

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

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

2.5.1. हार्डवेयर

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

  • [7.1.1.1/A-0-1] फ़ोन की स्क्रीन, डायगनल साइज़ में कम से कम छह इंच की होनी चाहिए.

  • [7.1.1.1/A-0-2] स्क्रीन साइज़ का लेआउट कम से कम 750 dp x 480 dp होना चाहिए.

  • [7.2.3/A-0-1] होम फ़ंक्शन देना ज़रूरी है. साथ ही, 'वापस जाएं' और 'हाल ही के' फ़ंक्शन उपलब्ध कराए जा सकते हैं.

  • [7.2.3/A-0-2] बैक फ़ंक्शन (KEYCODE_BACK) को दबाकर रखने वाले सामान्य और देर तक इवेंट, दोनों को फ़ोरग्राउंड ऐप्लिकेशन में भेजना ज़रूरी है.

  • [7.3.1/A-SR] इस्तेमाल करने का सुझाव दिया जाता है, जिसमें तीन-ऐक्सिस एक्सलरोमीटर शामिल करें.

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

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

  • [7.3.4/A-1-1] कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.

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

  • [7.3.11/A-0-1] SENSOR_TYPE_GEAR के तौर पर मौजूदा गियर उपलब्ध कराना ज़रूरी है.

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

  • [7.3.11.2/A-0-1] SENSOR_TYPE_NIGHT के तौर पर बताए गए दिन/रात वाले मोड के साथ काम करना ज़रूरी है.
  • [7.3.11.2/A-0-2] SENSOR_TYPE_NIGHT फ़्लैग की वैल्यू, डैशबोर्ड के दिन/रात वाले मोड के हिसाब से होनी चाहिए. साथ ही, यह आस-पास मौजूद लाइट सेंसर के इनपुट के हिसाब से होनी चाहिए.

  • बैकग्राउंड में मौजूद रोशनी मापने वाला सेंसर और फ़ोटोमीटर एक जैसा हो सकता है.

  • [7.3.11.4/A-0-1] SENSOR_TYPE_CAR_SPEED के मुताबिक, वाहन की स्पीड की जानकारी देना ज़रूरी है.

  • [7.3.11.5/A-0-1] SENSOR_TYPE_PARKING_BRAKE के मुताबिक, पार्किंग ब्रेक का स्टेटस देना ज़रूरी है.

  • [7.4.3/A-0-1] ज़रूरी है कि यह ब्लूटूथ के साथ काम करता हो और यह ब्लूटूथ LE के साथ काम करता हो.

  • [7.4.3/A-0-2] Android Automotive को लागू करने के लिए, इन ब्लूटूथ प्रोफ़ाइलों का इस्तेमाल करना ज़रूरी है:
    • हैंड्स-फ़्री प्रोफ़ाइल (एचएफ़पी) के ज़रिए फ़ोन कॉल करना.
    • ऑडियो डिस्ट्रिब्यूशन प्रोफ़ाइल (A2DP) पर मीडिया प्लेबैक.
    • रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) पर मीडिया प्लेबैक कंट्रोल.
    • फ़ोन बुक ऐक्सेस प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके, संपर्क शेयर करना.

  • [7.4.3/A-SR] का सुझाव दिया जाता है, ताकि मैसेज ऐक्सेस वाली प्रोफ़ाइल (मैप) के साथ काम किया जा सके.

  • [7.4.5/A] इसमें मोबाइल नेटवर्क पर आधारित डेटा कनेक्टिविटी की सुविधा शामिल होनी चाहिए.

  • [7.4.5/A] उन नेटवर्क के लिए System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID कॉन्स्टेंट का इस्तेमाल किया जा सकता है जो सिस्टम के ऐप्लिकेशन के लिए उपलब्ध होने चाहिए.

  • [7.6.1/A-0-1] ऐप्लिकेशन के निजी डेटा (यानी "/data" पार्टीशन) के लिए, कम से कम 4 जीबी का स्टोरेज खाली होना चाहिए.

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

  • [7.6.1/A] बेहतर परफ़ॉर्मेंस और फ़्लैश स्टोरेज की लंबे समय तक चलने वाली सुविधा देने के लिए डेटा विभाजन को फ़ॉर्मैट करना चाहिए, उदाहरण के लिए f2fs फ़ाइल सिस्टम का इस्तेमाल करना.

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

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

अगर Automotive डिवाइस में 32-बिट लागू होता है:

  • [7.6.1/A-1-1] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 512 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम
    • ज़्यादा बड़ी स्क्रीन पर ldpi या उससे कम
    • बड़ी स्क्रीन पर mdpi या कम

  • [7.6.1/A-1-2] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 608 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा
    • बड़ी स्क्रीन पर hdpi या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन के लिए mdpi या उससे ज़्यादा

  • [7.6.1/A-1-3] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 896 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
    • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन पर tvdpi या उसके बाद का वर्शन

  • [7.6.1/A-1-4] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1344 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा
    • बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

अगर Automotive डिवाइस में 64-बिट लागू होते हैं:

  • [7.6.1/A-2-1] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 816 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम
    • ज़्यादा बड़ी स्क्रीन पर ldpi या उससे कम
    • बड़ी स्क्रीन पर mdpi या कम

  • [7.6.1/A-2-2] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 944 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा
    • बड़ी स्क्रीन पर hdpi या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन के लिए mdpi या उससे ज़्यादा

  • [7.6.1/A-2-3] इनमें से किसी भी डेंसिटी का इस्तेमाल करने पर, कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
    • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन पर tvdpi या उसके बाद का वर्शन

  • [7.6.1/A-2-4] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1824 एमबी होनी चाहिए:

    • छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा
    • बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

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

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

  • [7.7.1/A] इसमें ऐसा यूएसबी पोर्ट होना चाहिए जो सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड के साथ काम करता हो.

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

  • [7.8.1/A-0-1] माइक्रोफ़ोन होना ज़रूरी है.

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

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

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

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

  • [5.1/A-0-1] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
  • [5.1/A-0-2] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [5.1/A-0-3] AAC ELD (कम देरी वाले AAC)

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

  • [5.2/A-0-1] H.264 एवीसी
  • [5.2/A-0-2] VP8

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

  • [5.3/A-0-1] H.264 एवीसी
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

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

  • [5.3/A-SR] H.265 एचईवीसी

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

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

  • [3/A-0-1] android.hardware.type.automotive सुविधा के बारे में बताना ज़रूरी है.

  • [3/A-0-2] uiMode = UI_MODE_TYPE_CAR के साथ काम करना ज़रूरी है.

  • [3/A-0-3] android.car.* नेमस्पेस में सभी सार्वजनिक एपीआई के साथ काम करना ज़रूरी है.

  • [3.4.1/A-0-1] android.webkit.Webview एपीआई को पूरी तरह लागू करना ज़रूरी है.

  • [3.8.3/A-0-1] तीसरे पक्ष के ऐप्लिकेशन के अनुरोध करने पर, उन सूचनाओं को दिखाना ज़रूरी है जो Notification.CarExtender एपीआई का इस्तेमाल करती हैं.

  • [3.8.4/A-SR] असिस्टेड ऐक्शन को मैनेज करने के लिए, डिवाइस पर असिस्टेंट का इस्तेमाल करने का सुझाव दिया जाता है.

  • [3.13/A-SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि 'क्विक सेटिंग' यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल किया जा सके.

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

  • [3.8.4/A-1-1] उपयोगकर्ता का चुना गया असिस्टेंट ऐप्लिकेशन लॉन्च करने के लिए, पुश-टू-टॉक बटन को दबाकर रखें. दूसरे शब्दों में, ऐसा ऐप्लिकेशन जो VoiceInteractionService को लागू करता है उसे लॉन्च किया जाना चाहिए.

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

  • [3.14/A-0-1] इसमें यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क शामिल करना ज़रूरी है. इससे, सेक्शन 3.14 में बताए गए तरीके से, मीडिया एपीआई इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन काम कर सकते हैं.

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

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

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

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

  • [8.2/A-0-1] हर प्रोसेस के यूआईडी के हिसाब से, डेटा को नॉन-वोलेटाइल स्टोरेज में पढ़े गए और लिखे गए बाइट की संख्या बताना ज़रूरी है. इससे डेवलपर को सिस्टम एपीआई android.car.storagemonitoring.CarStorageMonitoringManager के ज़रिए आंकड़े उपलब्ध कराए जाते हैं. Android ओपन सोर्स प्रोजेक्ट, uid_sys_stats कर्नेल मॉड्यूल के ज़रिए ज़रूरी शर्तें पूरी करता है.
  • [8.4/A-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देनी ज़रूरी है, जो हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू के बारे में बताती है. साथ ही, Android ओपन सोर्स प्रोजेक्ट की साइट पर मौजूद जानकारी के मुताबिक, समय के साथ कॉम्पोनेंट की वजह से बैटरी के तेज़ी से खर्च होने की अनुमानित जानकारी भी देती है.
  • [8.4/A-0-2] ऊर्जा खपत की सभी वैल्यू, मिलीयंपियर घंटे (mAh) में रिपोर्ट करनी ज़रूरी है.
  • [8.4/A-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल के लागू होने की ज़रूरी शर्तों को पूरा करता है.
  • [8.4/A] अगर किसी ऐप्लिकेशन के लिए हार्डवेयर कॉम्पोनेंट के पावर के इस्तेमाल की जानकारी नहीं दी जा सकती, तो इसे खुद हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.
  • [8.4/A-0-4] adb shell dumpsys batterystats शेल कमांड के ज़रिए, पावर के इस इस्तेमाल की जानकारी ऐप्लिकेशन डेवलपर को देनी होगी.

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

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

  • [9.5/A-1-1] एक गेस्ट खाता होना चाहिए. इससे वाहन के सिस्टम से मिलने वाली सभी सुविधाओं के लिए, उपयोगकर्ता को लॉग इन करने की ज़रूरत नहीं होनी चाहिए.

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

  • [9.9.2/A-1-1] पुष्टि करने वाली खास कुंजियों के हिसाब से, डेटा एन्क्रिप्ट (सुरक्षित) करने की सुविधा ज़रूरी है. फ़ाइल आधारित एन्क्रिप्शन (FBE) ऐसा करने का एक तरीका है.

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

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

2.6. टैबलेट की आवश्यकताएं

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

  • आम तौर पर, दोनों हाथों को पकड़कर इस्तेमाल किया जाता है.
  • इसमें क्लैमशेल या कन्वर्टेबल कॉन्फ़िगरेशन नहीं होता.
  • डिवाइस के साथ इस्तेमाल किए जाने वाले किसी भी फ़िज़िकल कीबोर्ड को स्टैंडर्ड कनेक्शन के ज़रिए कनेक्ट करना ज़रूरी है.
  • इसमें पावर सोर्स है जो चलने-फिरने की सुविधा देता है, जैसे कि बैटरी.
  • इनकी स्क्रीन का साइज़ 7 से 18 इंच के बीच होना चाहिए.

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

2.4.1. हार्डवेयर

स्क्रीन का साइज़

  • [7.1.1.1/Tab-0-1] फ़ोन की स्क्रीन 7 से 18 इंच के रेंज में होनी चाहिए.

कम से कम मेमोरी और स्टोरेज (सेक्शन 7.6.1)

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

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

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

  • [7.7.1/Tab] Android Open Accessory (AOA) API को लागू किया जा सकता है.

वर्चुअल रिएलिटी मोड (सेक्शन 7.9.1)

वर्चुअल रिएलिटी की बेहतर परफ़ॉर्मेंस (सेक्शन 7.9.2)

टैबलेट पर वर्चुअल रिएलिटी की शर्तें लागू नहीं हैं.

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

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

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

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

  • [C-0-1] Android SDK टूल या अपस्ट्रीम Android सोर्स कोड में “@SystemApi” मार्कर से सजाए गए किसी भी एपीआई के बारे में बताने के लिए, दस्तावेज़ में बताए गए सभी व्यवहार के साथ-साथ पूरी तरह लागू करने की ज़रूरत है.

  • [C-0-2] टेस्टएपीआई एनोटेशन (@TestApi) से मार्क की गई सभी क्लास, तरीकों, और उनसे जुड़े एलिमेंट को काम करना चाहिए या सुरक्षित रखना चाहिए.

  • [C-0-3] इस कंपैटिबिलिटी डेफ़िनिशन के तहत खास तौर से अनुमति वाले मामलों को छोड़कर, किसी भी मैनेज किए जा रहे एपीआई को छोड़ना, एपीआई इंटरफ़ेस या हस्ताक्षर में बदलाव नहीं करना चाहिए और न ही दस्तावेज़ में बताए गए तरीके से काम करना चाहिए और न ही कोई ऑपरेशन नहीं करना चाहिए.

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

  • [C-0-5] आपको तीसरे पक्ष के, छिपे हुए एपीआई के इस्तेमाल पर पाबंदी लगानी होगी. ये एपीआई, @hidden एनोटेशन से सजाए गए Android नेमस्पेस में एपीआई के तौर पर बताए गए हैं. SDK टूल के दस्तावेज़ों के मुताबिक, इन एपीआई को @SystemAPI या @TestApi के साथ नहीं. साथ ही, एओएसपी में सही एपीआई लेवल ब्रांच के लिए, prebuilts/runtime/appcompat/ पाथ में अस्थायी सूची और ब्लॉकलिस्ट फ़ाइलों के ज़रिए, प्रतिबंधित सूची में शामिल हर एपीआई के साथ शिप करें. हालांकि, वे:

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

3.1.1. Android एक्सटेंशन

Android में, एपीआई लेवल के वर्शन में बदलाव किए बिना, मैनेज किए गए एपीआई की अवधि बढ़ाई जा सकती है.

  • [C-0-1] Android डिवाइस पर, शेयर की गई लाइब्रेरी ExtShared और सेवा ExtServices, दोनों के लिए एओएसपी लागू करने की प्रोसेस पहले से लोड करनी होगी. इसमें हर एपीआई लेवल के हिसाब से, अनुमति वाले कम से कम या उसके बराबर के वर्शन भी पहले से लोड होने चाहिए. उदाहरण के लिए, Android 7.0 वाले डिवाइस पर एपीआई लेवल 24 लागू करते समय, इसमें कम से कम वर्शन 1 शामिल करना ज़रूरी है.

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

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

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

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

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

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

3.2.1. अनुमतियां

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

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

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

  • [C-0-1] डिवाइस को लागू करने के सभी तरीकों की एक जैसी और सही वैल्यू देने के लिए, नीचे दी गई टेबल में इन वैल्यू के फ़ॉर्मैट पर अतिरिक्त पाबंदियां दी गई हैं. ये पाबंदियां, उन वैल्यू के हिसाब से तय की जाती हैं जिनके मुताबिक डिवाइस को लागू करना ज़रूरी है.
पैरामीटर जानकारी
वर्शन.रिलीज़ मौजूदा समय में लागू हो रहे Android सिस्टम का ऐसा वर्शन जिसे कोई भी व्यक्ति आसानी से पढ़ सके. इस फ़ील्ड में, 9 में दी गई स्ट्रिंग की वैल्यू में से कोई एक होनी चाहिए.
वर्शन.SDK वर्तमान में चल रहे Android सिस्टम का वर्शन, जो तीसरे पक्ष के ऐप्लिकेशन कोड से ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में हो. Android 9 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 9_INT होनी चाहिए.
वर्शन.SDK_INT वर्तमान में चल रहे Android सिस्टम का वर्शन, जो तीसरे पक्ष के ऐप्लिकेशन कोड से ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में हो. Android 9 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 9_INT होनी चाहिए.
वर्शन.इंक्रीमेंटल डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जो हाल ही में लागू हो रहे Android सिस्टम के खास बिल्ड की जानकारी देती है. इस वैल्यू को कोई भी व्यक्ति आसानी से पढ़ सकता है. असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए, इस वैल्यू का फिर से इस्तेमाल नहीं किया जाना चाहिए. इस फ़ील्ड का सामान्य इस्तेमाल यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए किस बिल्ड नंबर या सोर्स-कंट्रोल चेंज आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड के खास फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है, बस यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
बोर्ड डिवाइस के अंदरूनी हार्डवेयर की पहचान करने के लिए, डिवाइस इंप्लिमेंटर की चुनी गई वैल्यू. इस वैल्यू को ऐसे फ़ॉर्मैट में लिखा जा सकता है जिसे कोई भी व्यक्ति आसानी से पढ़ सके. इस फ़ील्ड का संभावित इस्तेमाल, डिवाइस को चार्ज करने वाले बोर्ड के खास संशोधन को दिखाने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मैच होना चाहिए.
ब्रैंड डिवाइस से जुड़े ब्रैंड का नाम दिखाने वाली वैल्यू, जो असली उपयोगकर्ताओं को पता है. यह फ़ॉर्मैट, ऐसे फ़ॉर्मैट में होना चाहिए जिसे कोई भी व्यक्ति आसानी से पढ़ सके. साथ ही, यह डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का नाम होना चाहिए जिसके तहत डिवाइस को बेचा जाता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मैच होना चाहिए.
SUPPORTED_ABIS नेटिव कोड के निर्देश सेट का नाम (सीपीयू टाइप + एबीआई कन्वेंशन). सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
SUPPORTED_32_BIT_ABIS नेटिव कोड के निर्देश सेट का नाम (सीपीयू टाइप + एबीआई कन्वेंशन). सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
SUPPORTED_64_BIT_ABIS नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
सीपीयू_एबीआई नेटिव कोड के निर्देश सेट का नाम (सीपीयू टाइप + एबीआई कन्वेंशन). सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
सीपीयू (CPU_ABI2) नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
डिवाइस डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जिसमें डेवलपमेंट नाम या कोड का नाम होता है. यह वैल्यू, डिवाइस के हार्डवेयर की सुविधाओं के कॉन्फ़िगरेशन और डिवाइस के इंडस्ट्रियल डिज़ाइन के बारे में बताती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खाना चाहिए. प्रॉडक्ट के लाइफ़टाइम में इस डिवाइस का नाम नहीं बदलना चाहिए.
फ़िंगरप्रिंट प्रिंट इस बिल्ड की खास तौर पर पहचान करने वाली स्ट्रिंग. ऐसा होना चाहिए कि इसे कोई भी व्यक्ति आसानी से पढ़ सके. यह इस टेंप्लेट के हिसाब से होना चाहिए:

$(BRAND)/$(PRODUCT)/
$(DEVICE):$(VERSION.VERSION)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

उदाहरण के लिए:

acme/myproduct/
mydevice:9/LMYXX/3359:userdebug/test-keys

फ़िंगरप्रिंट में खाली सफ़ेद जगह नहीं होनी चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली सफ़ेद जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में अंडरस्कोर ("_") जैसे किसी दूसरे वर्ण से बदला जाना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है.

हार्डवेयर हार्डवेयर का नाम (कर्नेल कमांड लाइन या /proc से). ऐसा होना चाहिए कि इसे कोई भी व्यक्ति आसानी से पढ़ सके. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मैच होना चाहिए.
होस्ट एक ऐसी स्ट्रिंग जो खास तौर पर उस होस्ट की पहचान करती है जिस पर बिल्ड बनाया गया था. इस फ़ॉर्मैट में बनाए गए ऐप्लिकेशन को कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड के खास फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है, बस यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
आईडी ऐसा आइडेंटिफ़ायर जिसे डिवाइस लागू करने वाला व्यक्ति चुनता है. यह आइडेंटिफ़ायर किसी खास रिलीज़ के बारे में जानकारी देता है, जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. यह फ़ील्ड android.os.Build.VERSION.INCREMENTAL की तरह हो सकता है. हालांकि, असली उपयोगकर्ताओं के लिए यह एक अच्छा मान होना चाहिए, ताकि वे अलग-अलग सॉफ़्टवेयर बिल्ड के बीच अंतर कर सकें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मैच होना चाहिए.
निर्माता प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (OEM) के कारोबार का नाम. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, इसे शून्य या खाली स्ट्रिंग ("") के तौर पर सेट नहीं किया जाना चाहिए. प्रॉडक्ट के लाइफ़टाइम में यह फ़ील्ड नहीं बदलना चाहिए.
MODEL डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जिसमें डिवाइस का वह नाम होता है जो असली उपयोगकर्ता को पता है. यह वही नाम होना चाहिए जिसके तहत डिवाइस की मार्केटिंग की जाती है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, इसे शून्य या खाली स्ट्रिंग ("") के तौर पर सेट नहीं किया जाना चाहिए. प्रॉडक्ट के लाइफ़टाइम में यह फ़ील्ड नहीं बदलना चाहिए.
प्रॉडक्ट डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जिसमें उस प्रॉडक्ट (SKU) के डेवलपमेंट का नाम या कोड का नाम शामिल हो जो उसी ब्रैंड से अलग होना चाहिए. वीडियो ऐसे होने चाहिए जिन्हें लोग आसानी से पढ़ सकें. हालांकि, यह ज़रूरी नहीं है कि असली उपयोगकर्ता इसे देख पाएं. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खाना चाहिए. प्रॉडक्ट के लाइफ़टाइम में इस प्रॉडक्ट का नाम नहीं बदलना चाहिए.
सीरियल "UNKNOWN" होना चाहिए.
टैग डिवाइस लागू करने वाले की ओर से चुनी गई टैग की एक कॉमा-सेपरेटेड लिस्ट, जो बिल्ड को और भी अलग बनाती है. इस फ़ील्ड में, Android प्लैटफ़ॉर्म के साइनिंग तीन सामान्य कॉन्फ़िगरेशन की वैल्यू में से किसी एक की वैल्यू होनी चाहिए: रिलीज़-की, डेवलपर-की, और टेस्ट-की.
समय बिल्ड कब हुआ था, इसके टाइमस्टैंप को दिखाने वाली वैल्यू.
वाई-फ़ाई के टाइप के बारे में जानकारी डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन को तय करती है. इस फ़ील्ड में, Android रनटाइम के तीन सामान्य कॉन्फ़िगरेशन से मिलती-जुलती वैल्यू में से कोई एक वैल्यू होनी चाहिए: user, userdebug या eng.
उपयोगकर्ता बिल्ड जनरेट करने वाले उपयोगकर्ता (या अपने-आप काम करने वाले उपयोगकर्ता) का नाम या यूज़र आईडी. इस फ़ील्ड के खास फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है, बस यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
सुरक्षा_पैच बिल्ड के सिक्योरिटी पैच लेवल को दिखाने वाली वैल्यू. इसमें यह भी बताया जाना चाहिए कि Android के सार्वजनिक सुरक्षा से जुड़े बुलेटिन में बताई गई किसी भी समस्या से, बिल्ड को किसी भी तरह से खतरा नहीं होना चाहिए. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. यह स्ट्रिंग, Android के सार्वजनिक सुरक्षा बुलेटिन या Android सुरक्षा सलाह में बताई गई स्ट्रिंग से मेल खानी चाहिए. जैसे, "2015-11-01".
BASE_OS बिल्ड के FINGERprint पैरामीटर को दिखाने वाली वैल्यू. यह वैल्यू इस बिल्ड से मिलती-जुलती है. हालांकि, इसमें Android Public Security Notifications में दिए गए पैच शामिल नहीं हैं. इसमें सही वैल्यू की रिपोर्ट होनी चाहिए और अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") की रिपोर्ट करें.
बूटलोडर डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए जा रहे बूटलोडर के खास वर्शन की पहचान करती है. यह वैल्यू ऐसे फ़ॉर्मैट में होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मैच होना चाहिए.
getRadioVersion() ज़रूरी है कि डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, डिवाइस में इस्तेमाल होने वाले इंटरनल रेडियो/मॉडम के उस वर्शन की पहचान करे जिसे कोई भी व्यक्ति आसानी से पढ़ सके. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडम नहीं है, तो उसे शून्य करना होगा. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खाना चाहिए.
getSerial() एक हार्डवेयर सीरियल नंबर होना (होना चाहिए या वापस करना हो) जो एक ही MODEL और MANUFACTURER के साथ सभी डिवाइसों पर उपलब्ध और अलग होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खाना चाहिए.

3.2.3. इंटेंट के साथ काम करना

3.2.3.1. मुख्य ऐप्लिकेशन इंटेंट

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

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

    • डेस्क क्लॉक
    • ब्राउज़र
    • Calendar
    • संपर्क
    • गैलरी
    • वैश्विक खोज
    • लॉन्चर
    • संगीत
    • सेटिंग
3.2.3.2. इंटेंट रिज़ॉल्यूशन

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

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

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

  • हालांकि, जब डिफ़ॉल्ट गतिविधि डेटा यूआरआई के लिए ज़्यादा खास विशेषता मुहैया कराती है, तो डिवाइस को लागू करने के तरीके की मदद से खास यूआरआई पैटर्न (उदाहरण के लिए, http://play.google.com) के लिए डिफ़ॉल्ट गतिविधियां दी जा सकती हैं. उदाहरण के लिए, डेटा यूआरआई “http://www.android.com” को बताने वाला इंटेंट फ़िल्टर पैटर्न, “http://” के लिए ब्राउज़र के कोर इंटेंट पैटर्न की तुलना में ज़्यादा खास होता है.

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

  • [C-0-4] आपको डिजिटल ऐसेट लिंक की खास बातों में बताए गए पुष्टि करने के तरीके अपनाकर, किसी भी इंटेंट फ़िल्टर की पुष्टि करनी होगी. यह तरीका, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट के पैकेज मैनेजर में लागू किया गया है.
  • [C-0-5] ऐप्लिकेशन इंस्टॉल करते समय, इंटेंट फ़िल्टर की पुष्टि करने की कोशिश ज़रूर करनी चाहिए. साथ ही, पुष्टि किए गए सभी यूआरआई इंटेंट फ़िल्टर को अपने यूआरआई के लिए डिफ़ॉल्ट ऐप्लिकेशन हैंडलर के तौर पर सेट करना चाहिए.
  • खास यूआरआई इंटेंट फ़िल्टर को उनके यूआरआई के लिए डिफ़ॉल्ट ऐप्लिकेशन हैंडलर के तौर पर सेट कर सकता है, अगर उनकी पुष्टि हो जाती है, लेकिन दूसरे कैंडिडेट यूआरआई फ़िल्टर की पुष्टि नहीं हो पाती है. अगर किसी डिवाइस पर ऐसा किया जाता है, तो उसके लिए सेटिंग मेन्यू में हर यूआरआई पैटर्न में बदलाव के लिए उपयोगकर्ता को सही जानकारी देनी ज़रूरी है.
  • उपयोगकर्ता को सेटिंग में जाकर, हर ऐप्लिकेशन के लिए लिंक के अलग-अलग कंट्रोल उपलब्ध कराने होंगे. इसके लिए, यह तरीका अपनाएं:
    • [C-0-6] उपयोगकर्ता के पास यह विकल्प होना चाहिए कि वह किसी ऐप्लिकेशन के डिफ़ॉल्ट ऐप्लिकेशन लिंक के काम करने के तरीके को पूरी तरह बदल सके: हमेशा खुला, हमेशा पूछें या कभी न खोलें. यह विकल्प सभी कैंडिडेट यूआरआई इंटेंट फ़िल्टर पर एक जैसा लागू होना चाहिए.
    • [C-0-7] यह ज़रूरी है कि उपयोगकर्ता, कैंडिडेट यूआरआई इंटेंट फ़िल्टर की सूची देख सके.
    • डिवाइस को लागू करने से उपयोगकर्ता को उन खास कैंडिडेट यूआरआई इंटेंट फ़िल्टर को ओवरराइड करने की सुविधा मिल सकती है जिनकी पुष्टि हर इंटेंट के आधार पर सफलतापूर्वक की गई थी.
    • [C-0-8] डिवाइस पर लागू किए गए खास कैंडिडेट यूआरआई इंटेंट फ़िल्टर को देखने और बदलने की सुविधा उपयोगकर्ताओं को उपलब्ध करानी ज़रूरी है. ऐसा तब ही किया जा सकता है, जब डिवाइस पर लागू करने वाले कुछ कैंडिडेट यूआरआई इंटेंट फ़िल्टर की मदद से पुष्टि की जा सके, जबकि कुछ पर काम न करे.
3.2.3.3. इंटेंट नेमस्पेस
  • [C-0-1] डिवाइस पर Android का ऐसा कोई कॉम्पोनेंट शामिल नहीं होना चाहिए जो Android या com.android. नेमस्पेस में ACTION, CATEGORY या अन्य मुख्य स्ट्रिंग का इस्तेमाल करके, किसी भी नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न के मुताबिक काम करता हो.
  • [C-0-2] डिवाइस लागू करने वाले लोगों को Android के ऐसे कॉम्पोनेंट शामिल नहीं करने चाहिए जो दूसरे संगठन से जुड़े पैकेज स्पेस में ACTION, CATEGORY या अन्य मुख्य स्ट्रिंग का इस्तेमाल करके नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न के हिसाब से काम करते हों.
  • [C-0-3] डिवाइस लागू करने वाले लोगों को सेक्शन 3.2.3.1 में दिए गए मुख्य ऐप्लिकेशन में इस्तेमाल किए गए किसी भी इंटेंट पैटर्न में बदलाव नहीं करना चाहिए और न ही उसे बढ़ाना चाहिए.
  • डिवाइस को लागू करने में, नेमस्पेस का इस्तेमाल करके इंटेंट पैटर्न शामिल किए जा सकते हैं. ये पैटर्न, साफ़ तौर पर और साफ़ तौर पर उनके संगठन से जुड़े होते हैं. यह पाबंदी, सेक्शन 3.6 में Java लैंग्वेज क्लास के लिए बताए गए नियमों के मुताबिक है.
3.2.3.4. ब्रॉडकास्ट इंटेंट

तीसरे पक्ष के ऐप्लिकेशन, हार्डवेयर या सॉफ़्टवेयर एनवायरमेंट में होने वाले बदलावों की सूचना देने के लिए, प्लैटफ़ॉर्म पर भरोसा करते हैं. इसकी मदद से, वे कुछ खास मकसद को ब्रॉडकास्ट करते हैं.

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

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

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

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

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

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

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

  • [C-2-1] आपको एक सेटिंग मेन्यू देना होगा, जो डिफ़ॉल्ट एसएमएस ऐप्लिकेशन को बदलने के लिए एक डायलॉग दिखाने के मकसद से android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल करेगा.

  • [C-2-2] उपयोगकर्ता को डिफ़ॉल्ट फ़ोन ऐप्लिकेशन बदलने की अनुमति देने के लिए एक डायलॉग दिखाने के लिए, android.telecom.action.CHANGE_DEFAULT_DIALER के इंटेंट का पालन करना ज़रूरी है.

    • इनकमिंग और आउटगोइंग कॉल के लिए, उपयोगकर्ता के चुने गए डिफ़ॉल्ट Phone ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना होगा. हालांकि, आपातकालीन कॉल करने के लिए, पहले से इंस्टॉल किए गए Phone ऐप्लिकेशन का इस्तेमाल नहीं किया जाएगा.

  • [C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS का इस्तेमाल करके, उपयोगकर्ता को PhoneAccounts से जुड़े ConnectionServices खाते को कॉन्फ़िगर करना ज़रूरी है. साथ ही, इस डिफ़ॉल्ट Phoneखाते का इस्तेमाल करके, टेलिकम्यूनिकेशन सेवा देने वाली कंपनी आउटगोइंग कॉल कर सकती है. एओएसपी को लागू करने की प्रक्रिया, "कॉल" सेटिंग मेन्यू में "कॉल करने वाले खातों का विकल्प" मेन्यू शामिल करके इस ज़रूरी शर्त को पूरा करती है.

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

  • [C-3-1] टैप करके पेमेंट करने के लिए, ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग का मेन्यू दिखाने के लिए, android.settings.एनएफ़सी_PAYMENT_SETTINGS के इंटेंट का पालन करना ज़रूरी है.

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

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

3.2.4. सेकंडरी डिसप्ले पर गतिविधियां

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

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

अगर डिवाइस लागू करने की सुविधा की मदद से, सेकंडरी डिसप्ले पर सामान्य Android गतिविधियां लॉन्च की जाती हैं, तो प्राइमरी और सेकंडरी डिसप्ले में अलग-अलग android.util.DisplayMetrics होते हैं:

  • [C-2-1] सेकंडरी डिसप्ले पर, साइज़ नहीं बदली जा सकने वाली गतिविधियां (ऐसी गतिविधियां जो AndroidManifest.xml में resizeableActivity=false हैं) और एपीआई लेवल 23 या उससे पहले के लेवल को टारगेट करने वाले ऐप्लिकेशन को अनुमति नहीं देनी चाहिए.

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

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

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

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

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

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

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

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

  • [C-0-1] एक या उससे ज़्यादा तय एबीआई के साथ काम करना ज़रूरी है. साथ ही, यह Android एनडीके (NDK) के साथ काम करना चाहिए.
  • [C-0-2] स्टैंडर्ड Java नेटिव इंटरफ़ेस (जेएनआई) सिमेंटिक्स का इस्तेमाल करके, नेटिव कोड में कॉल करने के लिए, मैनेज किए जा रहे एनवायरमेंट में कोड के साथ काम करना ज़रूरी है.
  • [C-0-3] नीचे दी गई सूची में दी गई सभी ज़रूरी लाइब्रेरी के साथ, सोर्स और बाइनरी के साथ काम करने वाला (एबीआई के लिए) और बाइनरी के साथ काम करने वाला होना चाहिए.
  • [C-0-5] ज़रूरी है कि डिवाइस पर काम करने वाले नेटिव ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) की सटीक रिपोर्ट दी जाए. इसके लिए, android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, और android.os.Build.SUPPORTED_64_BIT_ABIS पैरामीटर का इस्तेमाल किया जाना चाहिए. इसमें, एबीआई की सबसे ज़्यादा से लेकर सबसे कम पसंदीदा सूची के क्रम में मौजूद हर एबीआई की सूची, कॉमा लगाकर अलग की गई है.

  • [C-0-6] ऊपर दिए गए पैरामीटर का इस्तेमाल करके, एबीआई की इस सूची के सबसेट को रिपोर्ट करें. साथ ही, ऐसे किसी भी एबीआई की रिपोर्ट न दें जो सूची में शामिल नहीं है.

    • armeabi
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64

    • [C-0-7] नेटिव कोड वाले ऐप्लिकेशन के लिए, नेटिव एपीआई उपलब्ध कराते हुए इन सभी लाइब्रेरी को बनाना ज़रूरी है:

    • libaaudio.so (ऑडियो नेटिव ऑडियो सहायता)

    • libandroid.so (Android गतिविधि से जुड़ी नेटिव सुविधा)
    • libc (C लाइब्रेरी)
    • libcamera2ndk.so
    • libdl (डाइनैमिक लिंकर)
    • libEGL.so (मूल OpenGL सरफ़ेस मैनेजमेंट)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (Android लॉगिंग)
    • libmediandk.so (नेटिव मीडिया एपीआई के लिए सहायता)
    • libm (गणित की लाइब्रेरी)
    • libneuralnetworks.so (न्यूरल नेटवर्क एपीआई)
    • libOpenMAXAL.so (OpenMAX AL 1.0.1 सहायता)
    • libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो सहायता)
    • libRS.so
    • libstdc++ (C++ के लिए कम से कम काम)
    • libvulkan.so (Vulkan)
    • libz (Zlib कंप्रेशन)
    • जेएनआई इंटरफ़ेस

  • [C-0-8] ऊपर दी गई नेटिव लाइब्रेरी के लिए सार्वजनिक फ़ंक्शन को जोड़ना या हटाना ज़रूरी नहीं है.

  • [C-0-9] /vendor/etc/public.libraries.txt में, ऐसी अन्य लाइब्रेरी की जानकारी देना ज़रूरी है जो तीसरे पक्ष के ऐप्लिकेशन में सीधे तौर पर नहीं दिखती हैं.
  • [C-0-10] एपीआई लेवल 24 या उसके बाद के लेवल को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन को, तीसरे पक्ष के ऐप्लिकेशन को ऐसी कोई दूसरी नेटिव लाइब्रेरी नहीं दिखानी चाहिए जो एओएसपी में सिस्टम लाइब्रेरी के तौर पर लागू और मुहैया कराई गई हो.
  • [C-0-11] आपको OpenGL ES 3.1 और Android एक्सटेंशन पैक फ़ंक्शन के सभी सिंबल एक्सपोर्ट करने होंगे, जैसा कि एनडीके में बताया गया है. इसे libGLESv3.so लाइब्रेरी की मदद से एक्सपोर्ट करना होगा. ध्यान दें कि सभी सिंबल का मौजूद होना ज़रूरी है. सेक्शन 7.1.4.1 में, ज़रूरी शर्तों के बारे में ज़्यादा जानकारी दी गई है. इससे यह पता चलेगा कि हर फ़ंक्शन को कब पूरी तरह लागू किया जाना चाहिए.
  • [C-0-12] libvulkan.so लाइब्रेरी से, Vulkan 1.0 के मुख्य फ़ंक्शन सिंबल के साथ-साथ VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए, फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे. ध्यान दें कि सभी सिंबल का मौजूद होना ज़रूरी है. सेक्शन 7.1.4.2 में, हर फ़ंक्शन के पूरी तरह लागू होने से जुड़ी ज़रूरी शर्तों के बारे में ज़्यादा जानकारी दी गई है.
  • इसे अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

ध्यान दें कि Android की आने वाली रिलीज़ में, अतिरिक्त एबीआई का इस्तेमाल किया जा सकता है.

3.3.2. 32-बिट ARM नेटिव कोड के साथ काम करता है

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

  • [C-3-1] armeabi-v7a के साथ भी काम करना ज़रूरी है, क्योंकि armeabi सिर्फ़ पुराने ऐप्लिकेशन के साथ काम करने की सुविधा के लिए है.

अगर इस बात की जानकारी दी जाती है कि डिवाइस पर लागू होने वाला armeabi-v7a एबीआई, इस एबीआई का इस्तेमाल करता है, तो इसका इस्तेमाल करने वाले ऐप्लिकेशन:

  • [C-2-1] /proc/cpuinfo में, नीचे दी गई लाइनें शामिल करनी चाहिए. साथ ही, एक ही डिवाइस पर वैल्यू में बदलाव नहीं करना चाहिए, भले ही उन्हें अन्य एबीआई ने पढ़ा हो.

    • Features:, इसके बाद ARMv7 सीपीयू की वैकल्पिक सुविधाओं की सूची, जो इस डिवाइस पर काम करती है.
    • CPU architecture:, इसके बाद एक पूर्णांक जो डिवाइस के साथ काम करने वाले सबसे बेहतर ARM आर्किटेक्चर की जानकारी देता है (उदाहरण के लिए, ARMv8 डिवाइसों के लिए, "8").

  • [C-2-2] इन कार्रवाइयों को हमेशा उपलब्ध रखना ज़रूरी है. ऐसा तब भी होना चाहिए, जब एबीआई को ARMv8 आर्किटेक्चर पर लागू किया गया हो. ऐसा या तो नेटिव सीपीयू सपोर्ट के ज़रिए या सॉफ़्टवेयर एम्युलेशन के ज़रिए किया जाता है:

    • SWP और SWPB के लिए निर्देश.
    • निर्देश सेट करें.
    • CP15ISB, CP15DSB, और CP15DMB बैरियर कार्रवाइयां.

  • [C-2-3] Advanced SIMD (यानी NEON) एक्सटेंशन के साथ काम करना ज़रूरी है.

3.4. वेब पर काम करता है

3.4.1. वेबव्यू के साथ काम करने की सुविधा

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

  • [C-1-1] android.software.webview को रिपोर्ट करना ज़रूरी है.
  • [C-1-2] android.webkit.WebView एपीआई को लागू करने के लिए, Android 9 ब्रांच पर अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से बनाए गए Chromium प्रोजेक्ट का इस्तेमाल करना ज़रूरी है.

  • [C-1-3] वेबव्यू से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [बिल्ड/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, जैसे Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • $(VERSION) स्ट्रिंग की वैल्यू, android.os.Build.VERSION. {1} की वैल्यू के बराबर होनी चाहिए.
    • $(MODEL) स्ट्रिंग खाली हो सकती है, लेकिन अगर यह खाली नहीं है, तो इसका मान android.os.Build.MODEL के समान होना चाहिए.
    • "बिल्ड/$(BUILD)" हटाया जा सकता है, लेकिन अगर यह मौजूद है, तो $(BUILD) स्ट्रिंग android.os.Build.ID की वैल्यू के बराबर होनी चाहिए.
    • $(CHROMIUM_VER) स्ट्रिंग का मान अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में Chromium का वर्शन होना चाहिए.
    • डिवाइस पर लागू होने वाली कार्रवाई से, उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को हटाया जा सकता है.

  • वेबव्यू कॉम्पोनेंट में ज़्यादा से ज़्यादा HTML5 सुविधाओं के साथ काम करने की सुविधा होनी चाहिए. साथ ही, अगर यह सुविधा काम करती है, तो इसे HTML5 स्पेसिफ़िकेशन के मुताबिक होना चाहिए.

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

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

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

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

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

3.5. एपीआई के व्यवहार के साथ काम करने की सुविधा

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

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

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

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

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

3.5.1. बैकग्राउंड की गतिविधियों पर पाबंदी

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

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

3.6. एपीआई नाम स्थान

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • com.android.*

इसका मतलब है कि:

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

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

  • [C-0-3] सार्वजनिक तौर पर सार्वजनिक किए गए किसी भी एपीआई के बताए गए व्यवहार और Java की भाषा में हस्ताक्षर पर असर नहीं डालना चाहिए.
  • [C-0-4] विज्ञापन नहीं दिखाए जाने चाहिए या डेवलपर को इसके बारे में नहीं बताया जाना चाहिए.

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

  • [C-0-5] ऐसे नेमस्पेस में नहीं होना चाहिए जिसका मालिकाना हक किसी दूसरे संगठन के पास हो या जो उससे जुड़ा हो. उदाहरण के लिए, डिवाइस लागू करने वाले लोगों को com.google.* या मिलते-जुलते नेमस्पेस में एपीआई नहीं जोड़ना चाहिए: सिर्फ़ Google ऐसा कर सकता है. इसी तरह, Google को दूसरी कंपनियों के नेमस्पेस में एपीआई नहीं जोड़ने चाहिए.
  • [C-0-6] को Android की शेयर की गई लाइब्रेरी में पैकेज करना ज़रूरी है, ताकि खास तौर पर इनका इस्तेमाल करने वाले ऐप्लिकेशन (<uses-library> तरीके से) पर इस तरह के एपीआई के ज़्यादा इस्तेमाल का असर पड़ा हो.

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

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

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

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

  • [C-0-1] यह ज़रूरी है कि फ़ील्ड में, Delvik exeutable (DEX) फ़ॉर्मैट और Dalvik बाइटकोड स्पेसिफ़िकेशन और सिमैंटिक की सुविधा दी गई हो.

  • [C-0-2] अपस्ट्रीम Android प्लैटफ़ॉर्म के हिसाब से मेमोरी असाइन करने के लिए, Delvik के रनटाइम को कॉन्फ़िगर करना ज़रूरी है. इसके बारे में इस टेबल में बताया गया है. (स्क्रीन के साइज़ और स्क्रीन की डेंसिटी से जुड़ी परिभाषाओं के लिए सेक्शन 7.1.1 देखें.)

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

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

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

स्क्रीन लेआउट स्क्रीन की सघनता कम से कम ऐप्लिकेशन मेमोरी
Android घड़ी 120 डीपीआई (ldpi) 32 एमबी
160 डीपीआई (एमडीपीआई)
213 dpi (tvdpi)
240 डीपीआई (एचडीपीआई) 36 एमबी
280 डीपीआई (280 डीपीआई)
320 डीपीआई (xhdpi) 48 एमबी
360 डीपीआई (360 डीपीआई)
400 डीपीआई (400 डीपीआई) 56 एमबी
420 डीपीआई (420 डीपीआई) 64 एमबी
480 डीपीआई (xxhdpi) 88 एमबी
560 डीपीआई (560 डीपीआई) 112 एमबी
640 डीपीआई (xxxhdpi) 154 एमबी
छोटा/सामान्य 120 डीपीआई (ldpi) 32 एमबी
160 डीपीआई (एमडीपीआई)
213 dpi (tvdpi) 48 एमबी
240 डीपीआई (एचडीपीआई)
280 डीपीआई (280 डीपीआई)
320 डीपीआई (xhdpi) 80 एमबी
360 डीपीआई (360 डीपीआई)
400 डीपीआई (400 डीपीआई) 96 एमबी
420 डीपीआई (420 डीपीआई) 112 एमबी
480 डीपीआई (xxhdpi) 128 एमबी
560 डीपीआई (560 डीपीआई) 192 एमबी
640 डीपीआई (xxxhdpi) 256 एमबी
बड़ा 120 डीपीआई (ldpi) 32 एमबी
160 डीपीआई (एमडीपीआई) 48 एमबी
213 dpi (tvdpi) 80 एमबी
240 डीपीआई (एचडीपीआई)
280 डीपीआई (280 डीपीआई) 96 एमबी
320 डीपीआई (xhdpi) 128 एमबी
360 डीपीआई (360 डीपीआई) 160 एमबी
400 डीपीआई (400 डीपीआई) 192 एमबी
420 डीपीआई (420 डीपीआई) 228 एमबी
480 डीपीआई (xxhdpi) 256 एमबी
560 डीपीआई (560 डीपीआई) 384 एमबी
640 डीपीआई (xxxhdpi) 512 एमबी
xlarge 120 डीपीआई (ldpi) 48 एमबी
160 डीपीआई (एमडीपीआई) 80 एमबी
213 dpi (tvdpi) 96 एमबी
240 डीपीआई (एचडीपीआई)
280 डीपीआई (280 डीपीआई) 144 एमबी
320 डीपीआई (xhdpi) 192 एमबी
360 डीपीआई (360 डीपीआई) 240 एमबी
400 डीपीआई (400 डीपीआई) 288 एमबी
420 डीपीआई (420 डीपीआई) 336 एमबी
480 डीपीआई (xxhdpi) 384 एमबी
560 डीपीआई (560 डीपीआई) 576 एमबी
640 डीपीआई (xxxhdpi) 768 एमबी

3.8. यूज़र इंटरफ़ेस के साथ काम करने की सुविधा

3.8.1. लॉन्चर (होम स्क्रीन)

Android में लॉन्चर ऐप्लिकेशन (होम स्क्रीन) और डिवाइस लॉन्चर (होम स्क्रीन) को बदलने के लिए तीसरे पक्ष के ऐप्लिकेशन की सुविधा शामिल है.

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

  • [C-1-1] प्लैटफ़ॉर्म के लिए उपलब्ध सुविधा android.software.home_screen का एलान करना ज़रूरी है.
  • [C-1-2] जब तीसरे पक्ष का ऐप्लिकेशन अपना आइकॉन देने के लिए <adaptive-icon> टैग का इस्तेमाल करता है, तो AdaptiveIconDrawable ऑब्जेक्ट दिखाना ज़रूरी है. साथ ही, आइकॉन वापस पाने के लिए PackageManager तरीके को कॉल करना ज़रूरी है.

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

  • [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.app_widgets के साथ काम करने का एलान करना ज़रूरी है.
  • [C-1-2] इसमें AppWidgets के लिए पहले से काम करने की सुविधा होनी चाहिए. साथ ही, ऐप्लिकेशन को सीधे लॉन्चर में जोड़ने, कॉन्फ़िगर करने, देखने, और हटाने के लिए यूज़र इंटरफ़ेस की सुविधाओं की जानकारी देनी ज़रूरी है.
  • [C-1-3] ज़रूरी है कि उन विजेट को रेंडर किया जा सके जो स्टैंडर्ड ग्रिड साइज़ में 4 x 4 के होते हैं. ज़्यादा जानकारी के लिए, Android SDK टूल से जुड़े दस्तावेज़ में ऐप्लिकेशन विजेट के डिज़ाइन से जुड़े दिशा-निर्देश देखें.
  • लॉक स्क्रीन पर ऐप्लिकेशन विजेट काम कर सकते हैं.

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

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

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

अगर लागू किए गए डिवाइस, फ़ीचर फ़्लैग android.hardware.ram.normal की रिपोर्ट करते हैं, तो वे:

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

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

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

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

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

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

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

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

  • [C-1-1] ऐसे एपीआई लागू करना ज़रूरी है जो तीसरे पक्ष के ऐप्लिकेशन को खोज बॉक्स में सुझाव जोड़ने की अनुमति देते हैं. यह अनुमति ग्लोबल सर्च मोड में चलाए जाने पर मिलती है.

अगर वैश्विक खोज का उपयोग करने वाला कोई तृतीय-पक्ष ऐप्लिकेशन इंस्टॉल नहीं है, तो:

  • डिफ़ॉल्ट तौर पर, वेब सर्च इंजन के नतीजे और सुझाव दिखाने चाहिए.

Android में सहायक API भी शामिल होता है, जिसकी मदद से ऐप्लिकेशन यह चुन सकते हैं कि डिवाइस पर सहायक के साथ वर्तमान संदर्भ की कितनी जानकारी शेयर की जाए.

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

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

3.8.5. अलर्ट और टोस्ट

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

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

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

  • [C-1-2] Toast API का इस्तेमाल बेहतर तरीके से करना ज़रूरी है. साथ ही, ऐप्लिकेशन में उपलब्ध असली उपयोगकर्ताओं को इस तरह से टोस्ट दिखाएं.

3.8.6. थीम

Android, ऐप्लिकेशन के लिए “थीम” उपलब्ध कराता है, ताकि वे पूरी ऐक्टिविटी या ऐप्लिकेशन में स्टाइल लागू कर सकें.

Android में “Holo” और "Material" थीम फ़ैमिली शामिल होती हैं. यह ऐप्लिकेशन डेवलपर के लिए, तय की गई स्टाइल का एक सेट है. इसका इस्तेमाल सिर्फ़ तब किया जा सकता है, जब डेवलपर को Holo थीम के लुक और स्टाइल के हिसाब से ऐप्लिकेशन का इस्तेमाल करना हो.

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

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

Android में “डिवाइस डिफ़ॉल्ट” थीम फ़ैमिली भी शामिल है. यह ऐप्लिकेशन डेवलपर के लिए, तय किए गए स्टाइल का एक सेट है. इसका इस्तेमाल तब किया जा सकता है, जब वे डिवाइस की थीम लागू करने वाले की ओर से तय की गई थीम के हिसाब से डिवाइस की थीम का इस्तेमाल करना चाहते हैं.

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

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

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

3.8.7. लाइव वॉलपेपर

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

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

  • डिवाइस पर लाइव वॉलपेपर का सही तरीके से इस्तेमाल करके, ऊपर बताए गए तरीके से लाइव वॉलपेपर का इस्तेमाल किया जाना चाहिए.

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

  • [C-1-1] प्लैटफ़ॉर्म की सुविधा वाले फ़्लैग के बारे में रिपोर्ट करना ज़रूरी है android.software.live_wallP.

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

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

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

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

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

3.8.9. इनपुट प्रबंधन

Android में इनपुट मैनेजमेंट की सुविधा और तीसरे पक्ष के इनपुट के तरीके के एडिटर की सुविधा शामिल है.

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

  • [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.input_methods के बारे में बताना ज़रूरी है. साथ ही, Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक IME API के साथ काम करना भी ज़रूरी है.
  • [C-1-2] android.settings.INPUT_METHOD_SETTINGS इंटेंट के हिसाब से, इनपुट के तीसरे पक्ष के तरीकों को जोड़ने और कॉन्फ़िगर करने के लिए, उपयोगकर्ता के लिए ऐक्सेस किया जा सकने वाला तरीका उपलब्ध कराना ज़रूरी है.

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

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

3.8.10. लॉक स्क्रीन पर मीडिया कंट्रोल

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

3.8.11. स्क्रीन सेवर (पहले इसे ड्रीम्स कहा जाता था)

Android में interactive स्क्रीनavers की सुविधा काम करती है. इसे पहले Dreams कहा जाता था. जब पावर सोर्स से कनेक्ट किया गया डिवाइस इस्तेमाल में न हो या डेस्क डॉक में डॉक हो, तब स्क्रीन सेवर की मदद से उपयोगकर्ता, ऐप्लिकेशन से इंटरैक्ट कर सकते हैं. Android Watch डिवाइसों पर स्क्रीन सेवर की सुविधा लागू हो सकती है. हालांकि, डिवाइस को लागू करने के अन्य तरीकों में स्क्रीन सेवर की सुविधा भी शामिल होनी चाहिए. साथ ही, उपयोगकर्ताओं को android.settings.DREAM_SETTINGS इंटेंट के हिसाब से, स्क्रीन सेवर कॉन्फ़िगर करने का सेटिंग विकल्प भी मिलना चाहिए.

3.8.12. जगह

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

3.8.13. यूनिकोड और फ़ॉन्ट

Android में यूनिकोड 10.0 में बताए गए इमोजी वर्णों के साथ काम करने की सुविधा शामिल है.

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

  • [C-1-1] इन इमोजी कैरेक्टर को कलर ग्लिफ़ में रेंडर करना ज़रूरी है.
  • [C-1-2] ज़रूरी है कि इन चीज़ों के लिए सहायता दी जाए:
    • डिवाइस पर उपलब्ध भाषाओं के लिए अलग-अलग मोटाई वाले Roboto 2 फ़ॉन्ट—sans-Serif-thin, San-Ser-light, San-ser-medium, San-Ser-black, San-ser-condensed, San-ser-condensed-light.
    • लैटिन, ग्रीक, और सिरिलिक के लिए यूनिकोड 7.0 का पूरा कवरेज. इसमें लैटिन एक्सटेंडेड A, B, C, और डी रेंज के साथ-साथ यूनिकोड 7.0 के मुद्रा सिंबल वाले ब्लॉक में मौजूद सभी ग्लिफ़ शामिल हैं.
  • यूनिकोड तकनीकी रिपोर्ट #51 के मुताबिक, त्वचा के रंग और परिवार के अलग-अलग तरह के इमोजी के साथ भी काम करना चाहिए.

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

  • इन इमोजी कैरेक्टर के लिए, उपयोगकर्ता को इनपुट का कोई तरीका उपलब्ध कराना चाहिए.

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

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

  • [C-1-1] Android SDK के मल्टी-विंडो मोड सहायता दस्तावेज़ में बताए गए ऐप्लिकेशन के व्यवहार और एपीआई के हिसाब से, इस तरह के मल्टी-विंडो मोड लागू करने होंगे. साथ ही, इन मोड को इन ज़रूरी शर्तों को पूरा करना होगा:
  • [C-1-2] ऐप्लिकेशन यह बता सकते हैं कि वे AndroidManifest.xml फ़ाइल में मल्टी-विंडो मोड में काम कर सकते हैं या नहीं. इसके लिए, या तो android:resizeableActivity एट्रिब्यूट को true पर सेट करें या फिर, targetSdkVersion > 24 की मदद से, साफ़ तौर पर यह बताया हो. जिन ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में साफ़ तौर पर इस एट्रिब्यूट को false पर सेट किया है उन्हें मल्टी-विंडो मोड में लॉन्च नहीं किया जाना चाहिए. targetSdkVersion < 24 वाले पुराने ऐप्लिकेशन, जिन्होंने इस android:resizeableActivity एट्रिब्यूट को सेट नहीं किया था उन्हें मल्टी-विंडो मोड में लॉन्च किया जा सकता है. हालांकि, सिस्टम को चेतावनी देनी होगी कि ऐप्लिकेशन शायद मल्टी-विंडो मोड में उम्मीद के मुताबिक काम न करे.
  • [C-1-3] अगर स्क्रीन की ऊंचाई 440 dp और स्क्रीन की चौड़ाई 440 dp से कम है, तो स्प्लिट स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं दी जानी चाहिए.
  • स्क्रीन साइज़ xlarge वाले डिवाइस को लागू करने के तरीके को फ़्रीफ़ॉर्म मोड पर काम करना चाहिए.

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

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

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

  • [C-3-1] ऐसी गतिविधियों को पिक्चर में पिक्चर मल्टी-विंडो मोड में लॉन्च करना ज़रूरी है जिनमें: * एपीआई लेवल 26 या उसके बाद के लेवल को टारगेट किया गया हो और android:supportsPictureInPicture * टारगेट एपीआई लेवल 25 या उससे कम के लेवल के साथ android:resizeableActivity और android:supportsPictureInPicture, दोनों के बारे में बताया गया हो.
  • [C-3-2] setActions() एपीआई की मदद से, अपने SystemUI में उन कार्रवाइयों को दिखाना ज़रूरी है जो मौजूदा पीआईपी गतिविधि में बताई गई हैं.
  • [C-3-3] setAspectRatio() एपीआई के ज़रिए, पीआईपी गतिविधि के मुताबिक, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) 1:2.39 और 2.39:1 के बराबर या उससे कम या इसके बराबर होना चाहिए.
  • [C-3-4] पीआईपी विंडो को कंट्रोल करने के लिए, KeyEvent.KEYCODE_WINDOW का इस्तेमाल करना ज़रूरी है. अगर पीआईपी मोड लागू नहीं है, तो फ़ोरग्राउंड गतिविधि के लिए पासकोड उपलब्ध होना चाहिए.
  • [C-3-5] उपयोगकर्ता को यह सुविधा देनी होगी कि वह किसी ऐप्लिकेशन को पीआईपी मोड में दिखने से रोक सके. एओएसपी को लागू करने के लिए, नोटिफ़िकेशन शेड में दिए गए कंट्रोल का इस्तेमाल करना ज़रूरी है.
  • [C-3-6] Configuration.uiMode को UI_MODE_TYPE_TELEVISION के तौर पर कॉन्फ़िगर करने पर, पीआईपी विंडो के लिए कम से कम चौड़ाई और ऊंचाई 108 dp और पीआईपी विंडो के लिए कम से कम 240 dp की ऊंचाई और 135 dp की ऊंचाई तय करना ज़रूरी है.

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

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

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

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

3.9. डिवाइस प्रबंधन

Android में ऐसी सुविधाएं शामिल हैं जो सुरक्षा की जानकारी देने वाले ऐप्लिकेशन को सिस्टम लेवल पर, डिवाइस के एडमिन फ़ंक्शन पूरे करने की अनुमति देती हैं. जैसे, Android Device Administration API की मदद से पासवर्ड नीतियां लागू करना या रिमोट वाइप करना.

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

  • [C-1-1] android.software.device_admin के बारे में एलान करना ज़रूरी है.
  • [C-1-2] सेक्शन 3.9.1 और सेक्शन 3.9.1.1 में बताए गए, डिवाइस के मालिक के प्रावधान के हिसाब से ज़रूरी है.

3.9.1 डिवाइस का प्रावधान करना

3.9.1.1 डिवाइस के मालिक का प्रावधान

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

  • [C-1-1] डिवाइस पॉलिसी क्लाइंट (डीपीसी) को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करने की सुविधा देनी ज़रूरी है. इसके बारे में नीचे बताया गया है:
    • अगर डिवाइस पर लागू करने के लिए, उपयोगकर्ता का कोई डेटा कॉन्फ़िगर नहीं किया गया है, तो यह:
      • [C-1-3] DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) के लिए, true को रिपोर्ट करना ज़रूरी है.
      • [C-1-4] इंटेंट कार्रवाई android.app.action.PROVISION_MANAGED_DEVICE के जवाब में, DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करना ज़रूरी है.
      • [C-1-5] अगर डिवाइस फ़ीचर फ़्लैग android.hardware.nfc के ज़रिए नियर-फ़ील्ड कम्यूनिकेशंस (एनएफ़सी) सहायता की घोषणा करता है और MIME टाइप MIME_TYPE_PROVISIONING_NFC वाला एक रिकॉर्ड वाला एनएफ़सी मैसेज मिलता है, तो उसे DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के रूप में रजिस्टर करना होगा.
    • लागू किए गए डिवाइस में उपयोगकर्ता का डेटा होने पर, यह:
      • [C-1-6] DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) के लिए, false को रिपोर्ट करना ज़रूरी है.
      • [C-1-7] अब किसी भी DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना होगा.
  • [C-1-2] डिवाइस के मालिक के तौर पर सेट किए जाने वाले ऐप्लिकेशन को सेट अप करने की सहमति देने के लिए, प्रावधान की प्रोसेस के दौरान कुछ कार्रवाई करना ज़रूरी है. प्रावधान करने के दौरान, उपयोगकर्ता की कार्रवाई या प्रोग्राम के हिसाब से अपने-आप होने वाली प्रोसेस के ज़रिए सहमति दी जा सकती है. हालांकि, इसे हार्ड कोड नहीं करना चाहिए और न ही डिवाइस के मालिक वाले अन्य ऐप्लिकेशन के इस्तेमाल से बचना चाहिए.

यदि डिवाइस कार्यान् वयन android.software.device_admin की घोषणा करता है, लेकिन उसके समाधान में एक मालिकाना डिवाइस स् वामी प्रबंधन समाधान भी शामिल होता है और मानक Android DevicePolicyManager API द्वारा पहचाने गए मानक "डिवाइस स् वामी" के रूप में "डिवाइस स् वामी के समतुल्य" के रूप में कॉन्फ़िगर किए गए ऐप् लिकेशन को बढ़ावा देने का तरीका प्रदान किया जाता है, तो वे:

  • [C-2-1] ज़रूरी है कि जिस ऐप्लिकेशन का प्रमोशन किया जा रहा है वह किसी वैध एंटरप्राइज़ डिवाइस मैनेजमेंट समाधान से जुड़ा हो. साथ ही, उसे "डिवाइस के मालिक" के तौर पर अधिकार पाने के लिए, पहले से ही मालिकाना हक वाले समाधान में कॉन्फ़िगर किया जा चुका हो.
  • [C-2-2] DPC ऐप्लिकेशन को "डिवाइस के मालिक" के तौर पर रजिस्टर करने से पहले, android.app.action.PROVISION_MANAGED_DEVICE के मुताबिक एओएसपी डिवाइस के मालिक की सहमति की जानकारी दिखाना ज़रूरी है.
  • DPC ऐप्लिकेशन को "डिवाइस के मालिक" के रूप में रजिस्टर करने से पहले, डिवाइस पर उपयोगकर्ता का डेटा हो सकता है.
3.9.1.2 मैनेज की जा रही प्रोफ़ाइल का प्रावधान

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

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

  • [C-1-2] मैनेज की जा रही प्रोफ़ाइल को मैनेज करने की प्रोसेस (android.app.action.PROVISION_MANAGED_PROFILE की ओर से शुरू किया गया फ़्लो), एओएसपी को लागू करने की प्रोसेस से मेल खानी चाहिए.

  • [C-1-3] डिवाइस पॉलिसी कंट्रोलर (DPC) की ओर से किसी खास सिस्टम फ़ंक्शन को बंद किए जाने पर, उपयोगकर्ता को इसकी जानकारी देने के लिए, सेटिंग में जाकर उपयोगकर्ता के लिए ये अनुमतियां देनी होंगी:

    • डिवाइस एडमिन ने किसी खास सेटिंग पर पाबंदी कब लगाई है, यह दिखाने के लिए एक जैसा आइकॉन या अन्य उपयोगकर्ता की कीमत (उदाहरण के लिए, अपस्ट्रीम एओएसपी की जानकारी का आइकॉन).
    • एक छोटा सा मैसेज, जो डिवाइस के एडमिन ने setShortSupportMessage में दिया है.
    • DPC ऐप्लिकेशन का आइकॉन.

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

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

  • [C-1-1] android.app.admin.DevicePolicyManager API का इस्तेमाल करके, मैनेज की जा रही प्रोफ़ाइल के साथ काम करना ज़रूरी है.
  • [C-1-2] सिर्फ़ एक या सिर्फ़ मैनेज की जा रही एक प्रोफ़ाइल बनाने की अनुमति होनी चाहिए.
  • [C-1-3] मैनेज किए जा रहे ऐप्लिकेशन और विजेट और हाल ही के और सूचनाएं जैसे बैज वाले दूसरे यूज़र इंटरफ़ेस (यूआई) एलिमेंट दिखाने के लिए, आइकॉन बैज (एओएसपी अपस्ट्रीम वर्क बैज की तरह) का इस्तेमाल करना ज़रूरी है.
  • [C-1-4] उपयोगकर्ता को यह बताने के लिए एक सूचना आइकॉन (एओएसपी अपस्ट्रीम वर्क बैज की तरह) दिखाना ज़रूरी है कि वह मैनेज किए जा रहे प्रोफ़ाइल ऐप्लिकेशन का इस्तेमाल कब करता है.
  • [C-1-5] डिवाइस के चालू होने पर (ACTION_USER_PRESENT) करने और फ़ोरग्राउंड ऐप्लिकेशन, मैनेज की जा रही प्रोफ़ाइल में मौजूद होने पर, उपयोगकर्ता को मैनेज की जा रही प्रोफ़ाइल का इस्तेमाल करते हुए दिखाने के लिए एक टोस्ट दिखाना ज़रूरी है.
  • [C-1-6] अगर मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो इंटेंट 'चुनने वाले' में उपयोगकर्ता को विज़ुअल खर्च दिखाने की अनुमति देनी होगी. इससे, उपयोगकर्ता, मैनेज की जा रही प्रोफ़ाइल से मुख्य उपयोगकर्ता को इंटेंट फ़ॉरवर्ड कर सकेगा. अगर डिवाइस पॉलिसी कंट्रोलर ने यह सेटिंग चालू की है, तो उपयोगकर्ता को मैनेज की जा रही प्रोफ़ाइल से प्राइमरी यूज़र को इंटेंट फ़ॉरवर्ड करने की अनुमति मिलनी चाहिए.
  • [C-1-7] अगर मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो प्राइमरी यूज़र और मैनेज की जा रही प्रोफ़ाइल, दोनों के लिए यहां दी गई उपयोगकर्ता की अनुमतियां शेयर करनी होंगी:
    • मुख्य उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल के लिए, बैटरी, जगह की जानकारी, मोबाइल डेटा, और स्टोरेज के इस्तेमाल को अलग-अलग करें.
    • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए वीपीएन ऐप्लिकेशन का स्वतंत्र मैनेजमेंट.
    • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए ऐप्लिकेशन का स्वतंत्र मैनेजमेंट.
    • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में खातों का स्वतंत्र मैनेजमेंट.
  • [C-1-8] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया डायलर, संपर्क और मैसेजिंग ऐप्लिकेशन, मैनेज की जा रही प्रोफ़ाइल (अगर कोई मौजूद हो) से कॉलर की जानकारी खोज सकते हैं और उसे देख सकते हैं. अगर डिवाइस नीति नियंत्रक अनुमति देता है, तो वह ऐसा कर सकता है.
  • [C-1-9] यह पक्का करना ज़रूरी है कि जिस डिवाइस पर एक से ज़्यादा उपयोगकर्ता चालू हैं उस पर सुरक्षा से जुड़ी सभी ज़रूरी शर्तें पूरी होती हैं (सेक्शन 9.5 देखें), भले ही मैनेज की जा रही प्रोफ़ाइल को मुख्य उपयोगकर्ता के अलावा किसी दूसरे उपयोगकर्ता के तौर पर न गिना गया हो.
  • [C-1-10] मैनेज की जा रही प्रोफ़ाइल में ऐप्लिकेशन का ऐक्सेस देने के लिए, नीचे दी गई ज़रूरी शर्तों के हिसाब से अलग से लॉक स्क्रीन सेट करने की सुविधा होनी चाहिए.
    • डिवाइस लागू करने के लिए DevicePolicyManager.ACTION_SET_NEW_PASSWORD का मकसद पूरा करना ज़रूरी है. साथ ही, मैनेज की जा रही प्रोफ़ाइल के लिए, लॉक स्क्रीन पर अलग से क्रेडेंशियल कॉन्फ़िगर करने के लिए इंटरफ़ेस दिखाना ज़रूरी है.
    • मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन पर दिखने वाले क्रेडेंशियल, पैरंट प्रोफ़ाइल की तरह ही क्रेडेंशियल स्टोरेज और मैनेजमेंट करने के तरीके का इस्तेमाल करते हैं, जैसा कि Android ओपन सोर्स प्रोजेक्ट साइट पर बताया गया है.
    • डीपीसी की पासवर्ड से जुड़ी नीतियां, सिर्फ़ मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन पर दिखने वाले क्रेडेंशियल पर लागू होनी चाहिए. ऐसा तब तक होना चाहिए, जब तक getParentProfile हटाएँ की मदद से दिए गए DevicePolicyManager इंस्टेंस का इस्तेमाल न किया जाए.
  • मैनेज की जा रही प्रोफ़ाइल के संपर्क, पहले से इंस्टॉल किए गए कॉल लॉग, कॉल के दौरान यूज़र इंटरफ़ेस (यूआई), जारी या मिस्ड कॉल की सूचनाओं, संपर्क, और मैसेजिंग ऐप्लिकेशन में दिखने पर, उन्हें उसी बैज के साथ बैज किया जाना चाहिए जो मैनेज किए जा रहे प्रोफ़ाइल ऐप्लिकेशन के लिए इस्तेमाल होता है.

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

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

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

3.10. सुलभता

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

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

  • [C-1-1] सुलभता एपीआई SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, Android सुलभता फ़्रेमवर्क को लागू करना ज़रूरी है.
  • [C-1-2] सुलभता इवेंट जनरेट करना और SDK में रजिस्टर किए गए सभी AccessibilityService लागू करने के सही तरीकों के हिसाब से AccessibilityEvent डिलीवर करना ज़रूरी है.
  • [C-1-3] android.settings.ACCESSIBILITY_SETTINGS के इंटेंट का पालन ज़रूर करना चाहिए, ताकि लोगों को आसानी से ऐक्सेस करने वाला सिस्टम दिया जा सके. इससे, पहले से इंस्टॉल की गई सुलभता सेवाओं के साथ-साथ तीसरे पक्ष की सुलभता सेवाओं को चालू और बंद किया जा सकेगा.
  • [C-1-4] सिस्टम के नेविगेशन बार में एक ऐसा बटन जोड़ना ज़रूरी है जिससे उपयोगकर्ता, सुलभता सेवा को कंट्रोल कर सके. ऐसा तब किया जाता है, जब चालू सुलभता सेवाएं AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON का एलान करती हैं. ध्यान दें कि बिना सिस्टम नेविगेशन बार के डिवाइस लागू करने पर, यह ज़रूरी नहीं है. हालांकि, डिवाइस लागू करने के लिए लोगों को इन सुलभता सेवाओं को कंट्रोल करने का खर्च मिलना चाहिए.

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

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

3.11. लिखे गए शब्दों को सुनने की सुविधा

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

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

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

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

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

Android Television इनपुट Framework (TIF) की मदद से, Android Television डिवाइसों पर लाइव कॉन्टेंट आसानी से डिलीवर किया जा सकता है. TIF, इनपुट मॉड्यूल बनाने के लिए स्टैंडर्ड एपीआई देता है. इन मॉड्यूल से Android Television डिवाइसों को कंट्रोल किया जा सकता है.

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

  • [C-1-1] प्लैटफ़ॉर्म के लिए उपलब्ध सुविधा android.software.live_tv का एलान करना ज़रूरी है.
  • [C-1-2] सभी TIF एपीआई के साथ काम करना ज़रूरी है. इससे, इन एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन और तीसरे पक्ष के टीआईएफ़ पर आधारित इनपुट सेवा को डिवाइस पर इंस्टॉल और इस्तेमाल किया जा सकता है.

3.13. फटाफट सेटिंग

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

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

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

3.14. मीडिया यूज़र इंटरफ़ेस (यूआई)

अगर डिवाइस पर लागू होने वाले यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क शामिल हैं, जो MediaBrowser और MediaSession पर निर्भर तीसरे पक्ष के ऐप्लिकेशन के साथ काम करते हैं, तो वे:

  • [C-1-1] MediaItem आइकॉन और सूचना आइकॉन को बिना बदलाव के दिखाना ज़रूरी है.
  • [C-1-2] मीडिया सेशन में बताए गए तरीके के हिसाब से इन आइटम को दिखाना ज़रूरी है. जैसे, मेटाडेटा, आइकॉन, इमेज.
  • [C-1-3] ऐप्लिकेशन का टाइटल दिखाना ज़रूरी है.
  • [C-1-4] MediaBrowser हैरारकी दिखाने के लिए, इसके पास एक पैनल या कोई अन्य तरीका होना चाहिए. साथ ही, MediaBrowser हैरारकी को इस्तेमाल करने वाले लोगों के लिए वह कीमत भी तय की जा सकती है.
  • [C-1-5] MediaSession.Callback#onMediaButtonEvent के लिए, KEYCODE_HEADSETHOOK या KEYCODE_MEDIA_PLAY_PAUSE पर KEYCODE_MEDIA_NEXT के तौर पर दो बार टैप करें.

3.15. Instant Apps

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

  • [C-0-1] इंस्टैंट ऐप्लिकेशन को सिर्फ़ ऐसी अनुमतियां दी जानी चाहिए जिनमें android:protectionLevel को "instant" पर सेट किया गया हो.
  • [C-0-2] इंस्टैंट ऐप्लिकेशन को इंप्लिसिट इंटेंट के ज़रिए, इंस्टॉल किए गए ऐप्लिकेशन के साथ तब तक इंटरैक्ट नहीं करना चाहिए, जब तक कि इनमें से कोई एक बात सही न हो:
    • कॉम्पोनेंट के इंटेंट पैटर्न का फ़िल्टर दिखाया गया है और उसमें CATEGORY_BROWSABLE है
    • कार्रवाई ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE में से एक है
    • टारगेट को android:visibleToInstantApps से साफ़ तौर पर ज़ाहिर किया जाता है
  • [C-0-3] इंस्टैंट ऐप्लिकेशन को, इंस्टॉल किए गए ऐप्लिकेशन के साथ साफ़ तौर पर तब तक इंटरैक्ट नहीं करना चाहिए, जब तक कि android:visibleToInstantApps के ज़रिए, कॉम्पोनेंट को बिना अनुमति के सार्वजनिक नहीं किया जाता.
  • [C-0-4] इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर इंस्टैंट ऐप्लिकेशन के बारे में तब तक जानकारी नहीं देखनी चाहिए, जब तक कि इंस्टैंट ऐप्लिकेशन साफ़ तौर पर इंस्टॉल किए गए ऐप्लिकेशन से कनेक्ट न हो जाए.

3.16. कंपैनियन डिवाइस को दूसरे डिवाइस से जोड़ना

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

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

  • [C-1-1] फ़ीचर फ़्लैग FEATURE_COMPANION_DEVICE_SETUP का एलान करना ज़रूरी है .
  • [C-1-2] यह पक्का करना ज़रूरी है कि android.companion पैकेज में मौजूद एपीआई पूरी तरह से लागू किए गए हों.
  • [C-1-3] उपयोगकर्ता को यह सुविधा देनी होगी कि उसके डिवाइस पर कोई साथी डिवाइस मौजूद है और वह इस्तेमाल में है, तो उसे चुनने या पुष्टि करने के लिए ज़रूरी है.

3.17. हैवीवेट ऐप्लिकेशन

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

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

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

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

4. ऐप्लिकेशन पैकेजिंग के साथ काम करती है

डिवाइस लागू करना:

  • [C-0-1] आपके डिवाइस पर Android “.apk” फ़ाइलों को इंस्टॉल करने और इस्तेमाल करने की सुविधा होनी चाहिए. ये फ़ाइलें, आधिकारिक Android SDK टूल में शामिल “aapt” टूल से जनरेट की गई हैं.
  • हालांकि, ऊपर बताई गई ज़रूरी शर्त को पूरा करना मुश्किल हो सकता है. इसलिए, एओएसपी रेफ़रंस के लिए लागू पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करने के लिए, डिवाइस को लागू करने का सुझाव दिया जाता है.

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

  • [C-0-2] APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2, और JAR साइनिंग का इस्तेमाल करके “.apk” फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.
  • [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या RenderScript बाइटकोड फ़ॉर्मैट में से किसी को भी इस तरह से इस्तेमाल नहीं करना चाहिए, जिससे वे फ़ाइलें, साथ काम करने वाले दूसरे डिवाइसों पर ठीक से इंस्टॉल न हो पाएं.

  • [C-0-4] पैकेज के लिए मौजूदा "इंस्टॉलर ऑफ़ रिकॉर्ड" के अलावा, किसी दूसरे ऐप्लिकेशन को उपयोगकर्ता की पुष्टि के बिना, अपने-आप ऐप्लिकेशन अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. यह जानकारी, DELETE_PACKAGE की अनुमति वाले SDK टूल में दी गई है. सिर्फ़ इस बात के अपवाद हैं कि सिस्टम पैकेज की पुष्टि करने वाला ऐप्लिकेशन, PACKAGE_NEEDS_VERIFICATION इंटेंट और स्टोरेज मैनेजर ऐप्लिकेशन ACTION_MANAGE_STORAGE इंटेंट को हैंडल कर रहा है.

  • [C-0-5] ज़रूरी है कि आपने android.settings.MANAGE_UNKNOWN_APP_SOURCES इंटेंट को मैनेज करने वाली कोई गतिविधि की हो.

  • [C-0-6] अज्ञात सोर्स से ऐप्लिकेशन पैकेज तब तक इंस्टॉल नहीं करना चाहिए, जब तक कि इंस्टॉल करने का अनुरोध करने वाला ऐप्लिकेशन इन सभी ज़रूरी शर्तों को पूरा न करता हो:

    • इसमें, REQUEST_INSTALL_PACKAGES की अनुमति का एलान करना ज़रूरी है या android:targetSdkVersion को 24 या उससे कम पर सेट किया जाना चाहिए.
    • इसे उपयोगकर्ता ने अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी होनी चाहिए.

  • अज्ञात सोर्स से हर ऐप्लिकेशन के लिए ऐप्लिकेशन इंस्टॉल करने की अनुमति देने/रद्द करने का अधिकार, उपयोगकर्ता को देना चाहिए. हालांकि, अगर डिवाइस लागू करने की स्थिति में उपयोगकर्ताओं को यह विकल्प नहीं देना है, तो उन्हें नो-ऑप के रूप में लागू करने और startActivityForResult() के लिए RESULT_CANCELED वापस करने का विकल्प दिया जाना चाहिए. हालांकि, ऐसे मामलों में भी, उन्हें उपयोगकर्ता को यह बताना चाहिए कि ऐसा कोई विकल्प क्यों नहीं दिया गया है.

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

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

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

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

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

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

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

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

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

5.1. मीडिया कोडेक

5.1.1. ऑडियो एन्कोडिंग

ज़्यादा जानकारी 5.1.3. ऑडियो कोडेक की जानकारी.

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

  • [C-1-1] पीसीएम/वेव

5.1.2. ऑडियो डिकोडिंग

ज़्यादा जानकारी 5.1.3. ऑडियो कोडेक की जानकारी.

अगर डिवाइस लागू करने की प्रक्रिया में यह बताया जाता है कि वह android.hardware.audio.output सुविधा के साथ काम करती है, तो उसे इन ऑडियो फ़ॉर्मैट को डिकोड करने की सुविधा देनी होगी:

  • [C-1-1] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
  • [C-1-2] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
  • [C-1-4] AAC ELD (कम देरी वाले AAC)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 एक्सटेंडेड HE AAC प्रोफ़ाइल, जिसमें USAC बेसलाइन प्रोफ़ाइल और ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल शामिल है)
  • [C-1-5] एफ़एलएसी
  • [C-1-6] एमपी3
  • [C-1-7] एमआईडीआई
  • [C-1-8] वोर्बिस
  • [C-1-9] पीसीएम/वेव
  • [C-1-10] ओपस

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

  • [C-2-1] डाउनमिक्सिंग के बिना ही डिकोड करना ज़रूरी है.उदाहरण के लिए, 5. 0 AAC स्ट्रीम को PCM के पांच चैनलों पर डिकोड करना ज़रूरी है.साथ ही, 5.1 AAC स्ट्रीम को PCM के छह चैनलों में डिकोड किया जाना चाहिए.
  • [C-2-2] डाइनैमिक रेंज मेटाडेटा के बारे में ISO/IEC 14496-3 के "डाइनैमिक रेंज कंट्रोल (डीआरसी)" सेक्शन में बताया जाना चाहिए. साथ ही, ऑडियो डिकोडर के डाइनैमिक रेंज से जुड़े व्यवहार को कॉन्फ़िगर करने के लिए, android.media.MediaFormat डीआरसी कुंजियों के बारे में बताना ज़रूरी है. AAC DRC कुंजियां, एपीआई 21 में पेश की गई थीं. ये कुंजियां हैं: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL, और KEY_AAC_ENCODED_TARGET_LEVEL.

यूएसएसी ऑडियो को डिकोड करते समय, MPEG-D (ISO/IEC 23003-4):

  • [C-3-1] आवाज़ और डीआरसी के मेटाडेटा की व्याख्या और इसे MPEG-D डीआरसी डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल लेवल 1 के मुताबिक समझा और लागू किया जाना चाहिए.
  • [C-3-2] डिकोडर को इन android.media.MediaFormat कुंजियों के साथ कॉन्फ़िगरेशन सेट के मुताबिक काम करना चाहिए: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL और KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4 AAC, HE AAC, और HE AACv2 प्रोफ़ाइल डिकोडर:

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

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

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

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

फ़ॉर्मैट/कोडेक जानकारी इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 एएसी प्रोफ़ाइल
(AAC LC) 		8 से 48 किलोहर्ट्ज़ के बीच, मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए, सैंपलिंग की मानक दरें लागू होती हैं.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS रॉ AAC (.aac, ADIF काम नहीं करता)
  • MPEG-TS (.ts, सीकेबल नहीं)
MPEG-4 HE AAC प्रोफ़ाइल (AAC+) 16 से 48 किलोहर्ट्ज़ के बीच स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए सहायता.
MPEG-4 HE AACv2
प्रोफ़ाइल (बेहतर AAC+) 		16 से 48 किलोहर्ट्ज़ के बीच स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए सहायता.
AAC ELD (बेहतर कम देरी AAC) 16 से 48 किलोहर्ट्ज़ के बीच स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो कॉन्टेंट के लिए सहायता.
यूएसएसी मोनो/स्टीरियो कॉन्टेंट के लिए, स्टैंडर्ड सैंपलिंग रेट 7.35 से 48 किलोहर्ट्ज़ के बीच होता है. MPEG-4 (.mp4, .m4a)
एएमआर-एनबी 4.75 से 12.2 केबीपीएस का सैंपल @ 8 किलोहर्ट्ज़ (kHz) 3GPP (.3gp)
एएमआर-डब्ल्यूबी 6.60 किलोहर्ट्ज़/से॰ से 23.85 किलोहर्ट्ज़/सेकंड तक 9 रेट, 16 किलोहर्ट्ज़ की दर से सैंपल किए गए
FLAC मोनो/स्टीरियो (मल्टीचैनल नहीं). 48 किलोहर्ट्ज़ तक के सैंपल रेट, लेकिन 44.1 किलोहर्ट्ज़ के आउटपुट वाले डिवाइसों पर 44.1 किलोहर्ट्ज़ तक के सैंपल रेट का सुझाव दिया जाता है. 48 से 44.1 किलोहर्ट्ज़ के डाउनसैंपलर में लो-पास फ़िल्टर शामिल नहीं होता है. 16-बिट का सुझाव दिया जाता है; 24-बिट के लिए कोई डीदर लागू नहीं किया जाता. सिर्फ़ FLAC (.flac)
MP3 मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर) एमपी3 (.mp3)
एमआईडीआई एमआईडीआई टाइप 0 और 1. DLS वर्शन 1 और 2. XMF और Mobile XMF. RTTTL/RTX, OTA, और iMelody फ़ॉर्मैट के साथ रिंगटोन इस्तेमाल करने की सुविधा
  • टाइप 0 और 1 (.mid, .xmf, .mxmf)
  • आरटीटीटीएल/आरटीएक्स (.rtttl, .rtx)
  • ओटीए (.ota)
  • iMelody (.imy)
वोर्बिस
  • ऑग (.ogg)
  • Matroska (.mkv, Android 4.0+)
PCM/WAVE 16-बिट लीनियर PCM (हार्डवेयर की सीमा तक की रेटिंग). डिवाइसों पर 8,000, 11,025, 16,000, और 44,100 हर्ट्ज़ फ़्रीक्वेंसी के हिसाब से सैंपलिंग रेट काम करना चाहिए. WAVE (.wav)
Opus मैट्रोस्का (.mkv), Ogg(.ogg)

5.1.4. चित्र एन्कोडिंग

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

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

  • [C-0-1] जेपीईजी
  • [C-0-2] PNG
  • [C-0-3] WebP

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

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

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

  • [C-0-1] जेपीईजी
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] रॉ
  • [C-0-7] HEIF (HEIC)

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)

5.1.7. वीडियो कोडेक

  • वेब वीडियो स्ट्रीमिंग और वीडियो कॉन्फ़्रेंस सेवाओं की अच्छी क्वालिटी के लिए, डिवाइस को लागू करने के लिए ऐसे हार्डवेयर VP8 कोडेक का इस्तेमाल करना चाहिए जो ज़रूरी शर्तें पूरी करता हो.

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

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

  • [C-1-2] वीडियो एन्कोडर और डिकोडर को YUV420 के सुविधाजनक कलर फ़ॉर्मैट (COLOR_FormatYUV420फ़्लेक्सिबल) के साथ काम करना ज़रूरी है.

अगर डिवाइस लागू करने की प्रोसेस के तहत, Display.HdrCapabilities के ज़रिए एचडीआर प्रोफ़ाइल से जुड़ी सहायता का विज्ञापन दिया जाता है, तो:

  • [C-2-1] एचडीआर के स्टैटिक मेटाडेटा को पार्स करने और हैंडल करने की सुविधा होनी चाहिए.

अगर डिवाइस लागू करने की सुविधा, MediaCodecInfo.CodecCapabilities क्लास में FEATURE_IntraRefresh के ज़रिए इंट्रा रीफ़्रेश सपोर्ट का विज्ञापन देती है, तो वे:

  • [C-3-1] रीफ़्रेश पीरियड, 10 से 60 फ़्रेम के बीच चलाए जा सकते हों. साथ ही, कॉन्फ़िगर की गई रीफ़्रेश अवधि के 20% के अंदर सटीक तरीके से काम करते हों.

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

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

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

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

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

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

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

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

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

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

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

5.2.1. एच.263

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

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

5.2.2. एच-264

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

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

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

  • [C-2-1] नीचे दी गई टेबल में, कोड में बदलने वाली प्रोफ़ाइल के साथ काम करना ज़रूरी है.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 240 पिक्सल 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 20 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 384 केबीपीएस 2 एमबीपीएस 4 एमबीपीएस 10 एमबीपीएस

5.2.3. वीपी8

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

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

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

  • [C-2-1] नीचे दी गई टेबल में, कोड में बदलने वाली प्रोफ़ाइल के साथ काम करना ज़रूरी है.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 180 पिक्सल 640 x 360 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 4 एमबीपीएस 10 एमबीपीएस

5.2.4. वीपी9

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

  • यह Matroska WebM फ़ाइल फ़ॉर्मैट में काम करने की सुविधा देता है.

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. एच.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

  • [C-2-1] नीचे दी गई टेबल में, एचडी 720 पिक्सल वीडियो डिकोड करने वाली प्रोफ़ाइलों का इस्तेमाल करना ज़रूरी है.
  • [C-2-2] नीचे दी गई टेबल में, एचडी 1080 पिक्सल वीडियो डिकोड करने वाली प्रोफ़ाइलों का इस्तेमाल करना ज़रूरी है.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 240 पिक्सल 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 60 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 FPS (60 FPS)टेलिविज़न)
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 8 एमबीपीएस 20 एमबीपीएस

5.3.5. H.265 (HEVC)

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

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

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

  • [C-2-1] डिवाइस पर एचडीआर क्वालिटी के वीडियो लागू करने के लिए, H.265 या VP9 में से किसी एक को डिकोड करना ज़रूरी है. इनमें से कम से कम एक पर 720, 1080, और यूएचडी प्रोफ़ाइल का इस्तेमाल किया जा सकता है.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
वीडियो रिज़ॉल्यूशन 352 x 288 पिक्सल 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30/60 FPS (60 FPS)H.265 हार्डवेयर डिकोडिंग के साथ टेलीविज़न) 60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 600 केबीपीएस 1.6 एमबीपीएस 4 एमबीपीएस 5 एमबीपीएस 20 एमबीपीएस

5.3.6. वीपी8

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

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

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

  • [C-2-1] नीचे दी गई टेबल में बताया गया है कि डिवाइस पर 720 पिक्सल वाली प्रोफ़ाइलों का इस्तेमाल किया जा सकता है या नहीं.
  • [C-2-2] नीचे दी गई टेबल में बताया गया है कि डिवाइस पर 1080 पिक्सल वाली प्रोफ़ाइलों का इस्तेमाल किया जा सकता है या नहीं.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 180 पिक्सल 640 x 360 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 FPS (60 FPS)टेलिविज़न) 30 (60 एफ़पीएस (फ़्रेम प्रति सेकंड)टेलीविज़न)
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 8 एमबीपीएस 20 एमबीपीएस

5.3.7. वीपी9

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

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

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

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

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

  • [C-3-1] डिवाइस पर 720, 1080, और यूएचडी प्रोफ़ाइलों के वर्शन को लागू करने के लिए, कम से कम VP9 या H.265 में से किसी एक को डिकोड करना ज़रूरी है.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
वीडियो रिज़ॉल्यूशन 320 x 180 पिक्सल 640 x 360 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 FPS (60 FPS)VP9 हार्डवेयर डिकोडिंग के साथ टेलीविज़न) 60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 600 केबीपीएस 1.6 एमबीपीएस 4 एमबीपीएस 5 एमबीपीएस 20 एमबीपीएस

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

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

5.4.1. रॉ ऑडियो कैप्चर

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

  • [C-1-1] इन चीज़ों के आधार पर, रॉ ऑडियो कॉन्टेंट रिकॉर्ड करने की अनुमति होनी चाहिए:

    • फ़ॉर्मैट: लीनियर PCM, 16-बिट
    • सैंपलिंग रेट: 8,000, 11,025, 16,000, 44,100 हर्ट्ज़
    • चैनल: मोनो

  • [C-1-2] सैंपल की दर के बिना, ऊपर बताई गई दर पर कैप्चर करना ज़रूरी है.

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

  • रॉ ऑडियो कॉन्टेंट को एएम रेडियो और डीवीडी क्वालिटी में कैप्चर करने की अनुमति होनी चाहिए, जिसका मतलब है कि ये विशेषताएं यहां दी गई हैं:

    • फ़ॉर्मैट: लीनियर PCM, 16-बिट
    • सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
    • चैनल: स्टीरियो

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

  • [C-2-1] 16000:22050 या 44100:48000 से ज़्यादा के किसी भी अनुपात में अप-सैंपलिंग के बिना कैप्चर करना ज़रूरी है.
  • [C-2-2] किसी भी अप-सैंपलिंग या डाउन-सैंपलिंग के लिए, एंटी-एलियाज़िंग फ़िल्टर शामिल करना ज़रूरी है.

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

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

  • [C-1-1] android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स को सैंपलिंग रेट, 44100 और 48,000 में से किसी एक पर कैप्चर करना ज़रूरी है.
  • [C-1-2] AudioSource.VOICE_RECOGNITION के ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, ग़ैर-ज़रूरी आवाज़ें कम करने वाली किसी भी तरह की ऑडियो प्रोसेसिंग को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.
  • [C-1-3] AudioSource.VOICE_RECOGNITION के ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, अपने-आप लागू होने वाले गेन कंट्रोल को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.
  • आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को फ़्रीक्वेंसी की तुलना में बिलकुल सपाट आयाम के साथ रिकॉर्ड किया जाना चाहिए: खास तौर पर, ±3 dB, 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक.
  • इनपुट की संवेदनशीलता को इस तरह सेट करके आवाज़ पहचानने वाली ऑडियो स्ट्रीम को रिकॉर्ड किया जाना चाहिए कि 1,000 हर्ट्ज़ पर साउंड पावर लेवल (एसपीएल) के किसी सोर्स से 16-बिट के सैंपल के लिए 2,500 आरएमएस मिलें.
  • आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि PCM आयाम स्तर इनपुट को रैखिक रूप से ट्रैक कर सकें SPL, माइक्रोफ़ोन पर कम से कम 30 dB की श्रेणी में -18 dB से +12 dB re 90 dB SPL तक बदल जाए.
  • आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को माइक्रोफ़ोन पर 90 dB SPL इनपुट स्तर पर, 1 किलोहर्ट्ज़ के लिए 1% से कम के टोटल हारमोनिक डिस्टॉर्शन (THD) के साथ रिकॉर्ड किया जाना चाहिए.

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

  • [C-2-1] इस ऑडियो के असर को अनुमति देनी होगी, ताकि इसे android.media.audiofx.NoiseSuppressor API की मदद से कंट्रोल किया जा सके.
  • [C-2-2] ज़रूरी है कि AudioEffect.Descriptor.uuid फ़ील्ड का इस्तेमाल करके, ग़ैर-ज़रूरी आवाज़ें कम करने वाली हर टेक्नोलॉजी को लागू करने के तरीके की खास तौर पर पहचान की जाए.

5.4.3. प्लेबैक को फिर से रूट करने के लिए कैप्चर करें

android.media.MediaRecorder.AudioSource क्लास में REMOTE_SUBMIX ऑडियो सोर्स शामिल होता है.

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

  • [C-1-1] REMOTE_SUBMIX ऑडियो सोर्स को सही तरीके से लागू करना ज़रूरी है, ताकि जब कोई ऐप्लिकेशन इस ऑडियो सोर्स से रिकॉर्ड करने के लिए android.media.AudioRecord एपीआई का इस्तेमाल करे, तो यह इन चीज़ों को छोड़कर सभी ऑडियो स्ट्रीम को मिलाकर दिखाए:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.5. ऑडियो प्लेबैक

Android में, ऐप्लिकेशन को ऑडियो आउटपुट वाले सहायक डिवाइसों (जैसे, सेक्शन 7.8.2 में बताया गया है) के ज़रिए ऑडियो चलाने की अनुमति देने की सुविधा शामिल है.

5.5.1. ऑडियो को चलाने की सुविधा

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

  • [C-1-1] इन चीज़ों के आधार पर, रॉ ऑडियो कॉन्टेंट चलाने की अनुमति होनी चाहिए:

    • फ़ॉर्मैट: लीनियर PCM, 16-बिट, 8-बिट, फ़्लोट
    • चैनल: मोनो, स्टीरियो, ज़्यादा से ज़्यादा आठ चैनलों के साथ मान्य मल्टीचैनल कॉन्फ़िगरेशन
    • सैंपलिंग रेट (हर्ट्ज़ में):
      • ऊपर दिए गए चैनल कॉन्फ़िगरेशन पर 8,000, 11,025, 16,000, 22,050, 32,000, 44,100, 48,000
      • मोनो और स्टीरियो में 96000

  • इन चीज़ों को ध्यान में रखकर, रॉ ऑडियो कॉन्टेंट चलाया जा सकता है:

    • सैंपलिंग रेट: 24,000, 48,000

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

Android, डिवाइस पर ऑडियो इफ़ेक्ट के लिए एपीआई उपलब्ध कराता है.

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

  • [C-1-1] ऑडियो इफ़ेक्ट की सब-क्लास Equalizer, LoudnessEnhancer से कंट्रोल किए जा सकने वाले EFFECT_TYPE_EQUALIZER और EFFECT_TYPE_LOUDNESS_ENHANCER को लागू करने की सुविधा दी जानी चाहिए.
  • [C-1-2] इसमें विज़ुअलाइज़र एपीआई लागू करने की सुविधा होनी चाहिए. इसे Visualizer क्लास से कंट्रोल किया जा सकता है.
  • [C-1-3] ऑडियो इफ़ेक्ट की सब-क्लास DynamicsProcessing के ज़रिए, EFFECT_TYPE_DYNAMICS_PROCESSING को लागू करने की प्रोसेस के साथ काम करना ज़रूरी है.
  • EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, और EFFECT_TYPE_VIRTUALIZER को लागू करने की प्रोसेस के साथ काम करना चाहिए. इसे AudioEffect सब-क्लास BassBoost, EnvironmentalReverb, PresetReverb, और Virtualizer के ज़रिए कंट्रोल किया जा सकता है.

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

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

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

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

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

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

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

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

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

अगर डिवाइस लागू करने की प्रोसेस ऊपर बताई गई ज़रूरी शर्तों को पूरा करती है, तो OpenSL ES PCM बफ़र सूची और AAudio नेटिव ऑडियो एपीआई, दोनों का इस्तेमाल करते समय, इन शर्तों को पूरा करने पर, आउटपुट में इंतज़ार का समय और कम से कम एक काम करने वाले ऑडियो आउटपुट डिवाइस पर, कोल्ड आउटपुट इंतज़ार के समय को लगातार देखा जा सकता है. ऐसे में, ये काम किए जाएंगे:

  • [C-SR] इस बात का सुझाव दिया जाता है कि android.hardware.audio.low_latency फ़ीचर फ़्लैग का एलान करके, इंतज़ार का समय कम रखने वाले ऑडियो की शिकायत की जाए.
  • [C-SR] ऑडियो एपीआई की मदद से, वीडियो स्ट्रीम होने और उसके दिखने के समय का अंतर कम होने से जुड़ी ज़रूरी शर्तों को पूरा करने का खास तौर पर सुझाव दिया जाता है.
  • [सी-एसआर] इस बात का खास तौर पर सुझाव दिया जाता है कि AAudioStream_getPerformanceMode() से AAUDIO_PERFORMANCE_MODE_LOW_LATENCY देने वाली स्ट्रीम के लिए, AAudioStream_getFramesPerBurst() से मिली वैल्यू, प्रॉपर्टी कुंजी AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER के लिए android.media.AudioManager.getProperty(String) से मिली वैल्यू से कम या उसके बराबर हो.

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

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

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

  • [C-SR] 100 मिलीसेकंड या उससे कम की कोल्ड इनपुट इंतज़ार का समय.
  • [C-SR] इनपुट में 30 मिलीसेकंड या उससे कम का लगातार इंतज़ार का समय.
  • [C-SR] 50 मिलीसेकंड या उससे कम की लगातार दोतरफ़ा यात्रा के इंतज़ार का समय.
  • [सी-एसआर] कोल्ड इनपुट सिग्नल की गड़बड़ी को कम करें.
  • [C-SR] इनपुट के टाइमस्टैंप में गड़बड़ी को सीमित करें, जैसा कि AudioRecord.gettimestamp या AAudioStream_getTimestamp से मिलने वाला है, +/- 1 मि॰से॰ तक.

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

डिवाइस पर ऑडियो और वीडियो चलाने के लिए, उन मीडिया नेटवर्क प्रोटोकॉल का पालन करना ज़रूरी है जिनकी जानकारी Android SDK के दस्तावेज़ में दी गई है.

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

  • [C-1-1] एचटीटीपी या एचटीटीपीएस पर सेक्शन 5.1 में, सभी ज़रूरी कोडेक और कंटेनर फ़ॉर्मैट काम करने चाहिए.

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

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

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

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

ऑडियो कोडेक:

  • AAC
AAC और उसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें.
ADTS फ़्रेमिंग और ID3 टैग के साथ AAC आईएसओ 13818-7 AAC और उसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT WebVTT

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] एमआईडीआई की मदद से काम करने वाले सभी हार्डवेयर ट्रांसपोर्ट के बजाय, एमआईडीआई की मदद से काम करना पड़ता है, जिनके लिए ये सामान्य नॉन-एमआईडीआई कनेक्टिविटी उपलब्ध कराते हैं. हालांकि, इस तरह के ट्रांसपोर्ट में ये शामिल होते हैं:

    • यूएसबी होस्ट मोड, सेक्शन 7.7
    • यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड, सेक्शन 7.7
    • एमआईडीआई ओवर ब्लूटूथ LE में मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3

  • [C-1-2] इंटर-ऐप्लिकेशन एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइसों) के साथ काम करना चाहिए

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

अगर डिवाइस लागू करने की सुविधा के ज़रिए android.content.pm.PackageManager क्लास के ज़रिए android.hardware.audio.pro सुविधा के लिए सहायता दी जाती है, तो वे:

  • [C-1-1] android.hardware.audio.low_latency सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
  • [C-1-2] दोतरफ़ा यात्रा के दौरान ऑडियो के इंतज़ार का समय, जैसा कि सेक्शन 5.6 में ऑडियो के इंतज़ार में लगने वाला समय में बताया जाना चाहिए, यह 20 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, यह कम से कम एक काम करने वाले पाथ से 10 मिलीसेकंड या उससे कम का होना चाहिए.
  • [C-1-3] यूएसबी होस्ट मोड और सहायक डिवाइस(जैसे- कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) के साथ काम करने वाले यूएसबी पोर्ट शामिल होने चाहिए.
  • [C-1-4] android.software.midi सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
  • [C-1-5] OpenSL ES पीसीएम बफ़र सूची और AAudio नेटिव ऑडियो एपीआई, दोनों का इस्तेमाल करके इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना होगा.
  • [SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि जब ऑडियो चालू हो और सीपीयू पर लोड अलग-अलग हो, तो सीपीयू की परफ़ॉर्मेंस एक जैसी रहे. इसकी जांच, SimpleSynth कमिट 1bd6391 का इस्तेमाल करके की जानी चाहिए. SimpleSynth ऐप्लिकेशन को नीचे दिए गए पैरामीटर के साथ चलाया जाना चाहिए और 10 मिनट के बाद, कोई अंडररन नहीं होना चाहिए:
    • काम के साइकल: 2,00,000
    • वैरिएबल लोड: चालू (यह हर दो सेकंड में वर्क साइकल की वैल्यू के 100% से 10% के बीच स्विच होगा और इसे सीपीयू के गवर्नर के व्यवहार की जांच करने के लिए डिज़ाइन किया गया है)
    • स्टेबलाइज़्ड लोड: बंद है
  • ऑडियो क्लॉक की गलतियों को कम से कम करना चाहिए और स्टैंडर्ड समय के हिसाब से ड्रिफ़्ट होना चाहिए.
  • जब दोनों चालू हों, तो सीपीयू CLOCK_MONOTONIC के मुकाबले ऑडियो क्लॉक ड्रिफ़्ट कम होना चाहिए.
  • डिवाइस पर मौजूद ट्रांसड्यूसर से, ऑडियो में देरी को कम किया जाना चाहिए.
  • USB डिजिटल ऑडियो पर ऑडियो प्रतीक्षा अवधि को कम करना चाहिए.
  • सभी पाथ के लिए, आवाज़ के इंतज़ार के समय को रिकॉर्ड करना चाहिए.
  • ऑडियो बफ़र पूरा होने के कॉलबैक से जुड़े एंट्री समय में, कंपन को कम करना चाहिए, क्योंकि इससे कॉलबैक के पूरे सीपीयू बैंडविथ के इस्तेमाल किए जा सकने वाले प्रतिशत पर असर पड़ता है.
  • रिपोर्ट की गई इंतज़ार के समय के लिए सामान्य इस्तेमाल पर, शून्य ऑडियो अंडररन (आउटपुट) या ओवररन (इनपुट) की जानकारी दी जानी चाहिए.
  • एक चैनल से दूसरे चैनल पर वीडियो अपलोड होने और उसके दिखने के बीच इंतज़ार के समय के अंतर का कोई अंतर नहीं होना चाहिए.
  • सभी ट्रांसपोर्ट के लिए, एमआईडीआई का मतलब कम से कम होना चाहिए.
  • सभी ट्रांसपोर्ट में, लोड (जीटर) में एमआईडीआई में देरी में होने वाले उतार-चढ़ाव को कम करना चाहिए.
  • सभी ट्रांसपोर्ट के लिए, एमआईडीआई के सटीक टाइमस्टैंप देने चाहिए.
  • कोल्ड स्टार्ट के तुरंत बाद के समय को भी, डिवाइस पर मौजूद ट्रांसड्यूसर पर ऑडियो सिग्नल के शोर को कम करना चाहिए.
  • दोनों के चालू होने पर, संबंधित एंड-पॉइंट के इनपुट और आउटपुट साइड के बीच ऑडियो क्लॉक का कोई अंतर नहीं होना चाहिए. डिवाइस के एंड-पॉइंट के उदाहरणों में, डिवाइस में मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट और आउटपुट शामिल हैं.
  • जब दोनों चालू हों, तब एक ही थ्रेड पर उससे जुड़े एंड-पॉइंट के इनपुट और आउटपुट साइड के लिए, ऑडियो बफ़र को पूरा करने वाले कॉलबैक को हैंडल करना चाहिए. साथ ही, इनपुट कॉलबैक से रिटर्न के तुरंत बाद, आउटपुट कॉलबैक को डालना चाहिए. इसके अलावा, अगर एक ही थ्रेड पर कॉलबैक मैनेज नहीं किए जा सकते, तो इनपुट कॉलबैक डालने के तुरंत बाद आउटपुट कॉलबैक डालें, ताकि ऐप्लिकेशन को इनपुट और आउटपुट साइड के समय में एक जैसा समय मिले.
  • इसके लिए, एंड पॉइंट के इनपुट और आउटपुट साइड के लिए, HAL ऑडियो बफ़रिंग के फ़ेज़ के अंतर को कम किया जाना चाहिए.
  • इसलिए, स्क्रीन पर टच होने में लगने वाले समय को कम किया जाना चाहिए.
  • लोड में टच इंतज़ार के समय में उतार-चढ़ाव को कम किया जाना चाहिए (जीटर).
  • टच इनपुट से लेकर ऑडियो आउटपुट तक, इंतज़ार का समय 40 मि॰से॰ या उससे कम होना चाहिए.

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

  • [SR] का सुझाव दिया जाता है कि android.content.pm.PackageManager क्लास के ज़रिए android.hardware.audio.pro सुविधा के लिए सहायता दी जाए.

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

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

  • [C-3-1] यूएसबी ऑडियो क्लास लागू करना ज़रूरी है.
  • [C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, ऑडियो के इंतज़ार का समय 20 मिलीसेकंड या उससे कम होना चाहिए.
  • यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, दोतरफ़ा यात्रा के ऑडियो के इंतज़ार का समय 10 मिलीसेकंड या उससे कम होना चाहिए.

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

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

5.11. प्रोसेस नहीं किए गए के लिए कैप्चर करें

Android में, android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स से प्रोसेस नहीं किए गए ऑडियो की रिकॉर्डिंग की सुविधा शामिल है. OpenSL ES में, इसे रिकॉर्ड प्रीसेट SL_ANDROID_RECORDING_PRESET_UNPROCESSED की मदद से ऐक्सेस किया जा सकता है.

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

  • [C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UN सहयोगी के ज़रिए सहायता की रिपोर्ट करना ज़रूरी है.

  • [C-1-2] ज़रूरी फ़्रीक्वेंसी रेंज में, डाइमेंशन और फ़्रीक्वेंसी की सामान्य फ़्रीक्वेंसी दिखाई जानी चाहिए: खास तौर पर, प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से 7,000 हर्ट्ज़ तक ±10dB.

  • [C-1-3] ऐसा किया जाना चाहिए कि कम फ़्रीक्वेंसी की रेंज में आयाम का लेवल दिखाया जाए: खास तौर पर, प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज की तुलना में ±20 dB से लेकर 5 हर्ट्ज़ से 100 हर्ट्ज़ तक.

  • [C-1-4] ऐसा होना चाहिए कि ज़्यादा फ़्रीक्वेंसी की रेंज में आयाम का लेवल दिखाया जाए: खास तौर पर, प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन की मिड फ़्रीक्वेंसी रेंज की तुलना में, खास तौर पर 7,000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक, 30 dB से लेकर 22 किलोहर्ट्ज़ तक.

  • [C-1-5] ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना ज़रूरी है कि 94 dB के साउंड प्रेशर लेवल (SPL) पर चलाए जाने वाले 1000 हर्ट्ज़ वाले साइनोसोइडल टोन सोर्स से 16 बिट-सैंपल (या फ़्लोट करने वाले पॉइंट/दोगुने सटीक सैंपल के लिए -36 dB फ़ुल स्केल) के लिए 520 के आरएमएस के साथ रिस्पॉन्स मिलता है.

  • [C-1-6] प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, 60 dB या इससे ज़्यादा का सिग्नल-टू-नॉइज़ रेशियो (SNR) होना ज़रूरी है. (वहीं एसएनआर को 94 dB SPL और खुद के शोर के बराबर के एसपीएल (A-वेट वाले) के बीच के अंतर के तौर पर मापा जाता है).

  • [C-1-7] प्रोसेस न किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन में, 90 dB SPL इनपुट लेवल पर 1 किलोहर्ट्ज़ के लिए 1% से कम हारमोनिक डिस्टॉर्शन (टीएचडी) होना चाहिए.

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

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

सभी एसपीएल मेज़रमेंट, जांच वाले माइक्रोफ़ोन के ठीक बगल में किए जाते हैं. कई माइक्रोफ़ोन कॉन्फ़िगरेशन के लिए, ये ज़रूरी शर्तें हर माइक्रोफ़ोन पर लागू होती हैं.

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

  • [C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) एपीआई तरीके के लिए null देना ज़रूरी है, ताकि इस गड़बड़ी के बारे में ठीक से बताया जा सके.
  • प्रोसेस न किए गए रिकॉर्डिंग सोर्स के सिग्नल पाथ की ज़रूरी शर्तों को पूरा करने के लिए, [SR] का बहुत ज़्यादा सुझाव दिया जाता है.

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

6.1. डेवलपर टूल

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

  • [C-0-1] Android SDK में दिए गए Android डेवलपर टूल के साथ काम करना ज़रूरी है.

  • Android डीबग ब्रिज (adb)

    • [C-0-2] Android SDK में बताए गए adb और एओएसपी में दिए गए शेल कमांड के साथ काम करना ज़रूरी है. इसका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys और cmd stats शामिल हैं.
    • [C-0-3] डंपसिस कमांड के ज़रिए लॉग किए गए डिवाइस के सिस्टम इवेंट (बैटरीस्टेट , डिस्कस्टेट, फ़िंगरप्रिंट, ग्राफ़िक्सस्टैट, नेटस्टेट, सूचना, प्रोस्टेट) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं करना चाहिए.
    • [C-0-10] ज़रूरी है कि आप इन्हें रिकॉर्ड करें और इन्हें बिना किसी गलती के रिकॉर्ड करें. साथ ही, इन इवेंट को cmd stats शेल कमांड और StatsManager System API क्लास में ऐक्सेस करने लायक और उपलब्ध कराना चाहिए.
      • ऐक्टिविटी फ़ोरग्राउंडस्टेटस
      • गड़बड़ी की पहचान हुई है
      • ऐप्लिकेशन ब्रेडक्रंब की रिपोर्ट की गई
      • AppCrash हुआ
      • AppStart हुआ
      • बैटरी स्तर में बदलाव
      • बैटरीसेवरमोडस्टेट बदलें
      • BleScanनतीजे मिला
      • BleScanStateChanged
      • ChargeStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • प्लग की गई स्थिति
      • शेड्यूल किए गए जॉबस्टेट में बदलाव
      • स्क्रीनस्टेट बदला गया
      • SyncStateChanged
      • सिस्टम बीता हुआ रीयलटाइम
      • UidProcessStateChanged
      • वेकलॉक स्टेट चेंज्ड
      • वेकअप अलार्म ट्रिगर हुआ
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • वाई-फ़ाईस्कैनस्टेट बदला गया
    • [C-0-4] डिवाइस-साइड adb डीमन डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android डीबग ब्रिज को चालू करने के लिए एक ऐसा तरीका होना चाहिए जिसे उपयोगकर्ता आसानी से ऐक्सेस कर सके.
    • [C-0-5] सुरक्षित adb के साथ काम करना चाहिए. Android में सुरक्षित adb की सुविधा शामिल है. सुरक्षित adb, पुष्टि किए गए जाने-पहचाने होस्ट पर adb चालू करता है.

    • [C-0-6] एक ऐसा तरीका उपलब्ध कराना ज़रूरी है जिससे adb को होस्ट मशीन से कनेक्ट किया जा सके. उदाहरण के लिए:

      • यूएसबी पोर्ट के बिना सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) को लागू करने के लिए, लोकल-एरिया नेटवर्क (जैसे ईथरनेट या वाई-फ़ाई) के ज़रिए adb लागू करना ज़रूरी है.
      • Windows 7, 9, और 10 के लिए ड्राइवर ज़रूरी हैं. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर सकते हैं.

  • Dalvik डीबग मॉनिटर सेवा (डीडीएम)

    • [C-0-7] Android SDK में बताए गए सभी डीडीएम सुविधाओं के साथ काम करना ज़रूरी है. ddms, adb का इस्तेमाल करता है, इसलिए ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब उपयोगकर्ता ऊपर बताए गए तरीके से Android डीबग ब्रिज को चालू करेगा, तो ddms के लिए सहायता बंद होनी चाहिए.
  • बंदर
    • [C-0-8] मंकी फ़्रेमवर्क शामिल करना ज़रूरी है और इसे ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है.
  • SysTrace
    • [C-0-9] Android SDK में बताए गए तरीके के मुताबिक, सिस्टम ट्रेस करने की सुविधा का इस्तेमाल करना ज़रूरी है. Systrace डिफ़ॉल्ट रूप से बंद होना चाहिए और उसमें Systrace की सुविधा चालू करने के लिए, एक ऐसा तरीका होना चाहिए जिसे उपयोगकर्ता आसानी से ऐक्सेस कर सके.

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

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

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

Android में, ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग कॉन्फ़िगर करने के लिए डेवलपर की सहायता शामिल है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] Android SDK के दस्तावेज़ में बताया गया है कि Configuration.screenLayout के लिए, लेआउट के सही साइज़ की जानकारी देना ज़रूरी है. खास तौर पर, लागू करने के लिए डिवाइस के लॉजिकल सघनता-इंडिपेंडेंट पिक्सल (डीपी) स्क्रीन डाइमेंशन की सही रिपोर्ट नीचे दी गई है:

    • जिन डिवाइसों पर Configuration.uiMode को यूज़र इंटरफ़ेस (यूआई) के अलावा, किसी भी अन्य वैल्यू के तौर पर सेट किया गया है और Configuration.screenLayout के लिए small साइज़ की रिपोर्टिंग की जा रही है उनके लिए, कम से कम 426 dp x 320 dp होना ज़रूरी है.
    • Configuration.screenLayout के लिए normal साइज़ की रिपोर्ट देने वाले डिवाइस में, कम से कम 480 dp x 320 dp होना ज़रूरी है.
    • Configuration.screenLayout के लिए large साइज़ की रिपोर्ट देने वाले डिवाइस में, कम से कम 640 dp x 480 dp होना ज़रूरी है.
    • Configuration.screenLayout के लिए xlarge साइज़ की रिपोर्ट देने वाले डिवाइस में, कम से कम 960 dp x 720 dp होना ज़रूरी है.

  • [C-0-2] यह ज़रूरी है कि आइटम, AndroidManifest.xml में <supports-screens> एट्रिब्यूट के ज़रिए, स्क्रीन साइज़ के लिए ऐप्लिकेशन के बताए गए काम करते हों, जैसा कि Android SDK के दस्तावेज़ में बताया गया है.

  • हो सकता है कि इसमें गोल किनारों वाला डिसप्ले हो.

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

  • [C-1-1] यह पक्का करना ज़रूरी है कि गोल किनारों का दायरा 38 dp से कम या उसके बराबर हो.
  • इसमें उपयोगकर्ता के लिए, आयताकार कोने वाले डिसप्ले मोड पर स्विच करने की कीमत शामिल होनी चाहिए.
7.1.1.2. स्क्रीन का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

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

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

    • ऐप्लिकेशन ने android.max_aspect मेटाडेटा वैल्यू के ज़रिए एलान किया है कि यह बड़ी स्क्रीन के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के साथ काम करता है.
    • ऐप्लिकेशन android:resizeableActivity एट्रिब्यूट के ज़रिए यह एलान करता है कि उसका साइज़ बदला जा सकता है.
    • यह ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के लेवल को टारगेट करता है. साथ ही, ऐप्लिकेशन के android:MaxAspectRatio के बारे में जानकारी नहीं देता है. इससे किसी तय आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) पर पाबंदी लग सकती है.

  • [C-0-2] जिन डिवाइसों पर Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट किया गया है उनके लिए आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) की वैल्यू 1.0 (1:1) पर सेट होनी चाहिए.

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

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

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

    • 120 डीपीआई (ldpi)
    • 160 डीपीआई (एमडीपीआई)
    • 213 dpi (tvdpi)
    • 240 डीपीआई (एचडीपीआई)
    • 260 डीपीआई (260 डीपीआई)
    • 280 डीपीआई (280 डीपीआई)
    • 300 डीपीआई (300 डीपीआई)
    • 320 डीपीआई (xhdpi)
    • 340 डीपीआई (340 डीपीआई)
    • 360 डीपीआई (360 डीपीआई)
    • 400 डीपीआई (400 डीपीआई)
    • 420 डीपीआई (420 डीपीआई)
    • 480 डीपीआई (xxhdpi)
    • 560 डीपीआई (560 डीपीआई)
    • 640 डीपीआई (xxxhdpi)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.4.1 OpenGL ES

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

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

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

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

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

  • [C-2-1] OpenGL ES से मैनेज किए जाने वाले एपीआई और नेटिव एपीआई के ज़रिए, उनके इस्तेमाल किए गए किसी अन्य OpenGL ES एक्सटेंशन की मदद से रिपोर्ट करनी चाहिए. साथ ही, उन एक्सटेंशन स्ट्रिंग की रिपोर्ट नहीं करनी चाहिए जिनके साथ वे काम नहीं करते.
  • [C-2-2] ज़रूरी है कि ये एक्सटेंशन EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, और EGL_ANDROID_recordable एक्सटेंशन के साथ काम करते हों.
  • EGL_KHR_p संक्षिप्त_update के साथ काम करने के लिए [SR] का बहुत ज़्यादा सुझाव दिया जाता है.
  • getString() तरीके का इस्तेमाल करके सटीक तरीके से रिपोर्ट की जानी चाहिए. यह तरीका, किसी भी टेक्सचर कंप्रेशन फ़ॉर्मैट के साथ काम करता है. यह फ़ॉर्मैट आम तौर पर वेंडर के लिए होता है.

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

  • [C-3-1] libGLESv2.so लाइब्रेरी में OpenGL ES 2.0 फ़ंक्शन सिंबल के अलावा, इन वर्शन के लिए संबंधित फ़ंक्शन सिंबल एक्सपोर्ट करने ज़रूरी हैं.

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

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

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

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

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

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

Android में Vulkan की सुविधा शामिल है. यह क्रॉस-प्लैटफ़ॉर्म एपीआई है, जो बेहतर परफ़ॉर्मेंस वाले 3D ग्राफ़िक्स के लिए बनाया गया है.

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

  • [SR] Vulkan 1.1 के साथ काम करने के लिए इसका सुझाव दिया जाता है.

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

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

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

  • [C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग का इस्तेमाल करके, सही पूर्णांक वैल्यू की रिपोर्ट करना ज़रूरी है.
  • [C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice की गिनती करना ज़रूरी है .
  • [C-1-3] गिनती किए गए हर VkPhysicalDevice के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
  • [C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() की मदद से, libVkLayer*.so नाम की नेटिव लाइब्रेरी में मौजूद लेयर की गिनती की जानी चाहिए .
  • [C-1-5] ऐप्लिकेशन पैकेज के बाहर मौजूद, लाइब्रेरी से मिली लेयर की गिनती नहीं करनी चाहिए या Vulkan API को ट्रेस करने या उसे रोकने के दूसरे तरीके नहीं बताना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो.
  • [C-1-6] उन सभी एक्सटेंशन स्ट्रिंग की रिपोर्ट करना ज़रूरी है जिनका इस्तेमाल वे Vulkan नेटिव एपीआई के ज़रिए करते हैं. इसके उलट , उन एक्सटेंशन स्ट्रिंग की रिपोर्ट भी नहीं करनी चाहिए जिनके साथ वे सही तरीके से काम नहीं करते.
  • [C-1-7] VK_KHR_Surface, VK_KHR_android_Surface, VK_KHR_swapchain, और VK_KHR_incremental_present एक्सटेंशन के साथ काम करना ज़रूरी है.

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

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

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

  • [C-3-1] SYNC_FD एक्सटर्नल सेमाफ़ोर और हैंडल टाइप के लिए सहायता देना ज़रूरी है.
  • VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के साथ काम करने के लिए, [SR] इस्तेमाल करने का सुझाव दिया जाता है.
7.1.4.3 रेंडरस्क्रिप्ट
  • [C-0-1] Android SDK के दस्तावेज़ में दी गई जानकारी के मुताबिक, डिवाइस पर Android RenderScript काम करना ज़रूरी है.
7.1.4.4 2D ग्राफ़िक ऐक्सेलरेशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.1. कीबोर्ड

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज़्म उपलब्ध न कराने के लिए, [SR] का बहुत ज़्यादा सुझाव दिया जाता है. ऐसा इसलिए, क्योंकि Android 4.0 और उसके बाद के वर्शन के लिए, ऐक्शन बार की सुविधा अब काम नहीं करती.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-3-1] android.hardware.touchscreen से शुरू होने वाले किसी फ़ीचर फ़्लैग की शिकायत नहीं करनी चाहिए और सिर्फ़ android.hardware.faketouch की रिपोर्ट करनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

7.2.6.1. बटन मैपिंग

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

  • [C-1-1] बॉक्स में एक कंट्रोलर या एक अलग कंट्रोलर लगाकर शिप करना ज़रूरी है. इससे, नीचे दी गई टेबल में दिए गए सभी इवेंट को इनपुट करने के तरीके मिलेंगे.
  • [C-1-2] एचआईडी इवेंट को, इससे जुड़े Android view.InputEvent कॉन्स्टेंट के साथ मैप किया जा सकता है. इनके बारे में नीचे दी गई टेबल में बताया गया है. अपस्ट्रीम Android को लागू करने के तरीके में, उन गेम कंट्रोलर के लिए सुविधा लागू करना शामिल है जो इस ज़रूरी शर्त को पूरा करते हैं.
बटन एचआईडी का इस्तेमाल2 Android बटन
जवाब1 0x09 0x001 KEYCODE_BUTTON_A (96)
ब1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x004 KEYCODE_BUTTON_X (99)
साल1 0x09 0x005 KEYCODE_BUTTON_Y (100)
डी-पैड ऊपर की ओर1
डी-पैड नीचे की ओर1 		0x01 0x00393 AXIS_HAT_Y4
बाईं ओर मौजूद डी-पैड1
डी-पैड दाईं ओर1 		0x01 0x00393 AXIS_HAT_X4
बाईं ओर का बटन1 0x09 0x007 KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन1 0x09 0x008 KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक1 0x09 0x000 KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक पर क्लिक करें1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
होम1 0x0c 0x0223 KEYCODE_HOME (3)
वापस जाएं1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

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

1 MotionEvent

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

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

7.3. सेंसर

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

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

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

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

  • [C-1-1] Android SDK के दस्तावेज़ में बताए गए हर तरह के सेंसर के लिए, इंटरनैशनल सिस्टम ऑफ़ यूनिट (मेट्रिक) की वैल्यू का इस्तेमाल करके सभी सेंसर मेज़रमेंट की रिपोर्ट ज़रूरी है.
  • [C-1-2] ऐप्लिकेशन प्रोसेसर के चालू होने पर, 5 मि॰से॰ + 2 * sample_time की कम से कम ज़रूरी इंतज़ार के समय के साथ स्ट्रीम किए जाने वाले सेंसर के मामले में, 100 मिलीसेकंड + 2 * sample_time की अधिकतम प्रतीक्षा समय के साथ सेंसर डेटा की रिपोर्ट करना ज़रूरी है. इस देरी में, फ़िल्टर करने में हुई देरी शामिल नहीं है.
  • [C-1-3] सेंसर के पहले सेंसर सैंपल की रिपोर्ट 400 मिलीसेकंड में + 2 * sample_time सेंसर करें. इस नमूने का 0 होना स्वीकार है.

  • [SR] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, नैनोसेकंड में इवेंट के समय की रिपोर्ट करनी चाहिए. इससे यह पता चलता है कि इवेंट कब हुआ और SystemClock.eलैप्स रीयलटाइमNano() घड़ी के साथ सिंक होने का समय क्या था. मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करने के लिए बहुत ज़्यादा सुझाया जाता है. ऐसा करने पर, उन्हें आने वाले प्लैटफ़ॉर्म की रिलीज़ पर अपग्रेड किया जा सकेगा, जहां यह एक ज़रूरी कॉम्पोनेंट बन सकता है. सिंक करने में गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए.

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

  • [C-1-5] को यह पक्का करना होगा कि सेंसर इवेंट की स्ट्रीम, डिवाइस के सीपीयू को निलंबित होने की स्थिति में जाने या निलंबित होने की स्थिति से स्क्रीन चालू होने से न रोकती हो.

  • कई सेंसर चालू होने पर, ऊर्जा की खपत, सेंसर में बताए गए बिजली की कुल खपत से ज़्यादा नहीं होनी चाहिए.

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

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

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

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

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

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

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

  • लागू किए जाने वाले डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल होना चाहिए.

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

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

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

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

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

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

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

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

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

  • डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर (कम्पास) शामिल होना चाहिए.

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

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

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

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

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

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

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

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

7.3.3. जीपीएस

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

  • GPS/GNSS रिसीवर शामिल होना चाहिए.

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

  • [C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, कम से कम एक हर्ट्ज़ की दर पर लोकेशन आउटपुट के साथ काम करना ज़रूरी है.
  • [C-1-2] 0.5 एमबीपीएस या तेज़ डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, ओपन-स्काई स्थितियों (मज़बूत सिग्नल, नगण्य मल्टीपाथ, एचडीओपी < 2) के अंदर 10 सेकंड (पहले ठीक करने में तेज़ समय) में जगह की जानकारी मिलनी ज़रूरी है. आम तौर पर, यह ज़रूरी शर्त, जीपीएस/जीएनएसएस लॉक-ऑन समय को कम करने के लिए, सहायता वाली या पहले से अनुमान लगाने वाली जीपीएस/जीएनएसएस तकनीक का इस्तेमाल करने से पूरी होती है. सहायक डेटा में रेफ़रंस का समय, रेफ़रंस की जगह की जानकारी, और सैटलाइट एफ़ेमेरीस/क्लॉक शामिल है.
    • [C-1-6] जगह की जानकारी का इस तरह से कैलकुलेशन करने के बाद, डिवाइस को खुले आसमान में पांच सेकंड के अंदर, जगह की जानकारी के अनुरोध फिर से शुरू होने पर, जगह की जानकारी के शुरुआती एक घंटे के अंदर इसकी जगह की जानकारी देनी ज़रूरी है. भले ही, बाद में किया जाने वाला अनुरोध बिना डेटा कनेक्शन के किया गया हो और/या पावर साइकल के बाद.

  • स्थान निर्धारित करने के बाद खुले आसमान की स्थितियों में, जबकि त्वरण के 1 मीटर प्रति सेकंड से कम वर्ग के साथ स्थिर या गति में:

    • [C-1-3] ज़रूरी है कि 20 मीटर के अंदर जगह की जानकारी हासिल की जा सके और कम से कम 95% समय में, 0.5 मीटर प्रति सेकंड के अंदर स्पीड पता चल जाए.
    • [C-1-4] GnssStatus.Callback की मदद से, किसी एक तारामंडल के कम से कम आठ उपग्रहों को एक साथ ट्रैक और रिपोर्ट करना ज़रूरी है.
    • एक से ज़्यादा तारामंडलों से, कम से कम 24 उपग्रहों को एक साथ ट्रैक किया जा सकेगा (उदाहरण के लिए, जीपीएस + कम से कम एक Glonass, Beidou, Galileo).
    • [C-1-5] टेस्ट एपीआई ‘getGnssYearOfHardware’ की मदद से GNSS टेक्नोलॉजी जनरेट करने की रिपोर्ट ज़रूर भेजें.
    • [SR] आपातकालीन फ़ोन कॉल के दौरान जीपीएस/जीएनएसएस की जगह की सामान्य जानकारी देना जारी रखें.
    • [SR] SBAS को छोड़कर, ट्रैक किए गए सभी तारामंडलों से GNSS मापों की रिपोर्ट करें (जैसा कि GnssStatus मैसेज में बताया गया है).
    • [SR] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की रिपोर्ट करें.
    • [SR] हर जीपीएस/जीएनएसएस लोकेशन के लिए, सटीक अनुमान की रिपोर्ट दें. इसमें बियरिंग, स्पीड, और वर्टिकल से जुड़े अनुमान भी शामिल हैं.
    • [SR] को टेस्ट एपीआई LocationManager.getGnssYearOfHardware() के ज़रिए साल "2016" या "2017" के लिए बनाई गई अतिरिक्त ज़रूरी शर्तों के मुताबिक ज़्यादा से ज़्यादा पूरा करने का सुझाव दिया जाता है.

अगर लागू करने वाले डिवाइस में जीपीएस/GNSS रिसीवर शामिल होता है और android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए ऐप्लिकेशन की क्षमता की जानकारी दी जाती है और LocationManager.getGnssYearOfHardware() Test API साल "2016" या इसके बाद के वर्शन की जानकारी देता है, तो वे:

  • [C-2-1] जीएनएसएस के माप मिलते ही, उनकी जानकारी देना ज़रूरी है. भले ही जीपीएस/जीएनएसएस से मिली जगह की जानकारी अभी तक रिपोर्ट न की गई हो.
  • [C-2-2] आपको GNSS pseudoranges और pseudorange रेट की रिपोर्ट देनी होगी. जगह की जानकारी तय करने के बाद, ओपन-स्काई स्थितियों में, 20 मीटर प्रति सेकंड वाले स्क्वेयर या 0.2 मीटर से कम के मूवमेंट के लिए, 20 मीटर के दायरे में पोज़िशन और 0.2 मीटर प्रति सेकंड के अंदर स्पीड का पता लगाना काफ़ी होगा.

अगर लागू किए जाने वाले डिवाइस में जीपीएस/GNSS रिसीवर शामिल होता है और android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए ऐप्लिकेशन की क्षमता की जानकारी दी जाती है और LocationManager.getGnssYearOfHardware() Test API साल "2017" या इसके बाद के वर्शन की जानकारी देता है, तो वे:

  • [C-3-1] आपातकालीन फ़ोन कॉल के दौरान, जीपीएस/जीएनएसएस की जगह की सामान्य जानकारी देते रहना ज़रूरी है.
  • [C-3-2] SBAS को छोड़कर, ट्रैक किए गए सभी तारामंडलों (जैसा कि GnssStatus मैसेज में बताया गया है) से GNSS मापों की रिपोर्ट करना ज़रूरी है.
  • [C-3-3] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की रिपोर्ट देनी ज़रूरी है.
  • [C-3-4] हर जीपीएस/जीएनएसएस लोकेशन के लिए, जगह के हिसाब से सभी सटीक अनुमान (इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं) की रिपोर्ट देनी ज़रूरी है.

अगर लागू किए गए डिवाइस में जीपीएस/जीएनएसएस रिसीवर शामिल है और android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए ऐप्लिकेशन की क्षमता की जानकारी दी जाती है और LocationManager.getGnssYearOfHardware() Test API साल "2018" या इसके बाद के वर्शन की जानकारी देता है, तो वे:

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

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

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

  • जाइरोस्कोप (एंगुलर चेंज सेंसर) का इस्तेमाल करना चाहिए.
  • जब तक 3-ऐक्सिस एक्सलरोमीटर भी शामिल न किया गया हो, तब तक जाइरोस्कोप सेंसर शामिल नहीं करना चाहिए.

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

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

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

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

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

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

7.3.5. बैरोमीटर

  • डिवाइस के साथ काम करने के लिए, बैरोमीटर (ऐंबियंट एयर प्रेशर सेंसर) शामिल होना चाहिए.

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

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

7.3.6. Thermometer

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

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

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

ध्यान दें कि Android 4.0 में, SENSOR_TYPE_TEMPERATURE सेंसर टाइप को बंद कर दिया गया है.

7.3.7. फ़ोटोमीटर

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

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

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

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

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

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

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

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

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

  • [C-2-1] ऐसा TYPE_ACCELEROMETER सेंसर होना चाहिए जो:

    • माप की रेंज कम से कम -8 ग्रा॰ और +8 ग्रा॰ के बीच होनी चाहिए. माप की रेंज कम से कम -16 ग्राम और +16 ग्राम के बीच होनी चाहिए.
    • रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
    • तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
    • इसे ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा मेज़रमेंट फ़्रीक्वेंसी का होना चाहिए; यह SensorDirectChannel RATE_VERY_FAST पर काम करना चाहिए.
    • तापमान मापने के लिए ज़रूरी नॉइज़ 400 μg/installHz से ज़्यादा नहीं होनी चाहिए.
    • इस सेंसर को चालू करने के लिए, कम से कम 3,000 सेंसर इवेंट की बफ़रिंग क्षमता का इस्तेमाल करें.
    • बैच में ऊर्जा की खपत 3 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
    • [C-SR] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि इस बैंडविड्थ में कम से कम 80% की 3dB मेज़रमेंट बैंडविड्थ और व्हाइट नॉइज़ स्पेक्ट्रम हो.
    • रैंडम रैंडम वॉक का होना चाहिए, जो 30 μg होस्ट हर्ट्ज़ से कम से कम हो. टेस्ट के लिए कमरे के तापमान को जांचा गया है.
    • तापमान में बदलाव होना चाहिए और ≤ +/- 1 mg/°C होना चाहिए.
    • सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.5% या इससे कम हो. साथ ही, तापमान की संवेदनशीलता के मुकाबले 0.03%/C° तापमान का तापमान कम या ज़्यादा होना चाहिए.
    • डिवाइस के इस्तेमाल के लिए सेट किए गए तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 2.5 % से कम और क्रॉस-ऐक्सिस की संवेदनशीलता के वैरिएशन में 0.2% से कम का अंतर होना चाहिए.

  • [C-2-2] ज़रूरी है कि TYPE_ACCELEROMETER_UNCALIBRATED में, TYPE_ACCELEROMETER जैसी क्वालिटी की शर्तें हों.

  • [C-2-3] ऐसा TYPE_GYROSCOPE सेंसर होना चाहिए जो:

    • माप की रेंज कम से कम -1000 और +1000 dps के बीच होनी चाहिए.
    • रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
    • तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
    • इसे ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा मेज़रमेंट फ़्रीक्वेंसी का होना चाहिए; यह SensorDirectChannel RATE_VERY_FAST पर काम करना चाहिए.
    • तापमान मापने के लिए ज़रूरी नॉइज़ 0.014°/s/प्रभावित हर्ट्ज़ से ज़्यादा नहीं होनी चाहिए.
    • [C-SR] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि इस बैंडविड्थ में कम से कम 80% की 3dB मेज़रमेंट बैंडविड्थ और व्हाइट नॉइज़ स्पेक्ट्रम हो.
    • कमरे के तापमान पर, रैंडम वॉक की दर 0.001 °/s 7Hz से कम होनी चाहिए.
    • तापमान में बदलाव होना चाहिए और तापमान ≤ +/- 0.05 °/ s / °C होना चाहिए.
    • 0.02% / °C के तापमान के मुकाबले संवेदनशीलता में बदलाव होना चाहिए.
    • सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.2% या इससे कम हो.
    • शोर की सघनता ≤ 0.007 °/s/होस्ट हर्ट्ज़ होनी चाहिए.
    • डिवाइस के स्थिर होने पर, उसका कैलिब्रेशन गड़बड़ी 0.002 रेड/से॰ से कम होना चाहिए 10 ~ 40 °C.
    • g-सेंसिटिविटी, 0.1°/s/g से कम होनी चाहिए.
    • डिवाइस के इस्तेमाल के लिए सेट किए गए तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता < 4.0 % और क्रॉस-ऐक्सिस की संवेदनशीलता के बदलाव 0.3% से कम होनी चाहिए.

  • [C-2-4] ज़रूरी है कि TYPE_GYROSCOPE_UNCALIBRATED में, TYPE_GYROSCOPE जैसी क्वालिटी की शर्तें हों.

  • [C-2-5] ऐसा TYPE_GEOMAGNETIC_FIELD सेंसर होना चाहिए जो:

    • तापमान मापने की रेंज कम से कम -900 और +900 μT के बीच होनी चाहिए.
    • रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
    • तापमान मापने की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
    • तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
    • तापमान मापने वाला नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.

  • [C-2-6] TYPE_MAGNETIC_FIELD_UNCALIBRATED में, TYPE_GEOMAGNETIC_FIELD जैसी क्वालिटी ज़रूरी शर्तें पूरी होनी चाहिए. इसके अलावा:

    • इस सेंसर को चालू करने के लिए, कम से कम 600 सेंसर इवेंट की बफ़रिंग सुविधा का इस्तेमाल करना ज़रूरी है.
    • [C-SR] रिपोर्ट की दर 50 हर्ट्ज़ या उससे ज़्यादा होने पर, 1 हर्ट्ज़ से कम से कम 10 हर्ट्ज़ तक व्हाइट नॉइज़ स्पेक्ट्रम रखने की सलाह दी जाती है.

  • [C-2-7] ऐसा TYPE_PRESSURE सेंसर होना चाहिए जो:

    • इसकी मेज़रमेंट रेंज कम से कम 300 से 1100 hPa के बीच होनी चाहिए.
    • रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए.
    • तापमान मापने की फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या इससे कम होनी चाहिए.
    • तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
    • तापमान मापने के लिए नॉइज़, 2 Pa/withHz से ज़्यादा नहीं होनी चाहिए.
    • इस सेंसर को चालू न करने की सुविधा का इस्तेमाल करना ज़रूरी है. इसमें कम से कम 300 सेंसर इवेंट की बफ़रिंग की सुविधा होनी चाहिए.
    • बैच में ऊर्जा की खपत दो मिलीवाट से कम नहीं होनी चाहिए.
  • [C-2-8] ऐसा TYPE_GAME_ROTATION_VECTOR सेंसर होना चाहिए जो:
    • इस सेंसर को चालू न करने की सुविधा का इस्तेमाल करना ज़रूरी है. इसमें कम से कम 300 सेंसर इवेंट की बफ़रिंग की सुविधा होनी चाहिए.
    • बैच में ऊर्जा की खपत 4 मिलीवाट से कम नहीं होनी चाहिए.
  • [C-2-9] ऐसा TYPE_SIGNIFICANT_MOTION सेंसर होना चाहिए जो:
    • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
  • [C-2-10] ऐसा TYPE_STEP_DETECTOR सेंसर होना चाहिए जो:
    • इस सेंसर को चालू न करने की सुविधा का इस्तेमाल करना ज़रूरी है. इसमें कम से कम 100 सेंसर इवेंट की बफ़रिंग की सुविधा होनी चाहिए.
    • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
    • बैच में ऊर्जा की खपत 4 मिलीवाट से कम नहीं होनी चाहिए.
  • [C-2-11] ऐसा TYPE_STEP_COUNTER सेंसर होना चाहिए जो:
    • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
  • [C-2-12] ऐसा TILT_DETECTOR सेंसर होना चाहिए जो:
    • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
  • [C-2-13] एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर की ओर से रिपोर्ट की गई एक ही शारीरिक घटना के इवेंट का टाइमस्टैंप, एक-दूसरे से 2.5 मिलीसेकंड के अंदर होना चाहिए. एक्सलरोमीटर और जाइरोस्कोप से रिपोर्ट किए गए, एक ही असल इवेंट का इवेंट टाइमस्टैंप एक-दूसरे से 0.25 मिलीसेकंड के अंदर होना चाहिए.
  • [C-2-14] जाइरोस्कोप सेंसर, इवेंट टाइमस्टैंप और कैमरा सबसिस्टम एक ही समय पर होने चाहिए. साथ ही, गड़बड़ी होने पर 1 मिलीसेकंड के अंदर होने चाहिए.
  • [C-2-15] ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर ऐप्लिकेशन के डेटा उपलब्ध होने पर, 5 मिलीसेकंड के अंदर ऐप्लिकेशन को सैंपल डिलीवर करना ज़रूरी है.
  • [C-2-16] डिवाइस के स्टैटिक होने पर 0.5 मिलीवाट से ज़्यादा बिजली की खपत नहीं होनी चाहिए. साथ ही, इन सेंसर का कोई भी कॉम्बिनेशन चालू होने पर 2.0 मिलीवाट से ज़्यादा बिजली की खपत नहीं होनी चाहिए:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर मौजूद है, तो कम से कम 100 सेंसर इवेंट की बफ़र क्षमता होना ज़रूरी है.

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

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

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

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

7.3.10.1. फ़िंगरप्रिंट सेंसर

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

  • इसमें फ़िंगरप्रिंट सेंसर होना चाहिए.

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

  • [C-1-1] ज़रूरी है कि यह android.hardware.fingerprint सुविधा के लिए काम करता हो.
  • [C-1-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, मिलते-जुलते एपीआई को पूरी तरह से लागू करना ज़रूरी है.
  • [C-1-3] गलती से स्वीकार किए जाने की दर 0.002% से ज़्यादा नहीं होनी चाहिए.
  • [SR] को स्पूफ़ और इंपोस्टर के तौर पर स्वीकार करने की दर 7% से ज़्यादा न रखने का सुझाव दिया जाता है.
  • [C-1-4] यह बताना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, अगर झूठे नाम से मेल भेजने और गुमराह करने वाले कॉन्टेंट को स्वीकार करने की दर 7% से ज़्यादा है, तो इसे चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
  • [C-1-5] फ़िंगरप्रिंट की पुष्टि के लिए पांच गलत ट्रायल के बाद, रेट लिमिट कम से कम 30 सेकंड के लिए सेट होनी चाहिए.
  • [C-1-6] ज़रूरी है कि आपके पास हार्डवेयर-बैक्ड कीस्टोर लागू करने की सुविधा हो. साथ ही, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में या टीईई के लिए एक सुरक्षित चैनल वाले चिप पर फ़िंगरप्रिंट का मिलान करना ज़रूरी है.
  • [C-1-7] ज़रूरी है कि फ़िंगरप्रिंट का डेटा एन्क्रिप्ट (सुरक्षित) किया गया हो और उसे क्रिप्टोग्राफ़िक तरीके से पुष्टि की गई हो. इसके अलावा, इन डेटा को टीईई के बाहर हासिल नहीं किया जा सकता, पढ़ा नहीं जा सकता या बदला नहीं जा सकता. इसके अलावा, टीईई के लिए एक सुरक्षित चैनल वाला चिप होना चाहिए, जैसा कि Android ओपन सोर्स प्रोजेक्ट की साइट पर लागू करने के दिशा-निर्देशों में दर्ज है.
  • [C-1-8] उपयोगकर्ता को पहचान की पुष्टि किए बिना या टीईई के सुरक्षित नया डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) जोड़कर, फ़िंगरप्रिंट जोड़ने से रोकना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट को लागू करने से, ऐसा करने के लिए फ़्रेमवर्क में तरीका बताया जाता है.
  • [C-1-9] फ़िंगरप्रिंट के बीच अंतर करने के लिए, तीसरे पक्ष के ऐप्लिकेशन को चालू नहीं करना चाहिए.
  • [C-1-10] DevicePolicyManager.KEYGUARD_ प्रमोशन_FINGERकिसी फ़्लैग का पालन करना ज़रूरी है.
  • [C-1-11] Android 6.0 से पहले के किसी वर्शन से अपग्रेड करने के बाद, ऊपर बताई गई ज़रूरी शर्तों को पूरा करने के लिए फ़िंगरप्रिंट का डेटा सुरक्षित तरीके से माइग्रेट करना होगा या उसे हटा देना होगा.
  • [C-1-12] उपयोगकर्ता का खाता हटाए जाने पर, उसके फ़िंगरप्रिंट का डेटा पूरी तरह से हटा देना ज़रूरी है. इसमें फ़ैक्ट्री रीसेट करना भी शामिल है.
  • [C-1-13] को पहचान ज़ाहिर करने वाले फ़िंगरप्रिंट डेटा या इससे मिले किसी भी डेटा (जैसे कि एम्बेड करना) को ऐप्लिकेशन प्रोसेसर को बिना एन्क्रिप्ट (सुरक्षित) किए ऐक्सेस करने की अनुमति नहीं देनी चाहिए.
  • [SR] के लिए काफ़ी सुझाव दिया जाता है, ताकि अस्वीकार किए जाने की दर 10% से कम हो. यह दर डिवाइस पर मापी जाती है.
  • [SR] एक सेकंड से कम का इंतज़ार करने का सुझाव दिया जाता है. यह फ़िंगरप्रिंट सेंसर को छूने से लेकर स्क्रीन अनलॉक किए जाने तक का तापमान मापा जाता है. यह जांच, रजिस्टर की गई एक उंगली के लिए की जाती है.
  • Android ओपन सोर्स प्रोजेक्ट में दिए गए Android फ़िंगरप्रिंट का आइकॉन इस्तेमाल करना चाहिए.
7.3.10.2. अन्य बायोमेट्रिक सेंसर

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

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

7.3.11. सिर्फ़ Android Automotive के लिए सेंसर

android.car.CarSensorManager API में, वाहन संबंधित खास सेंसर की जानकारी दी गई है.

7.3.11.1. मौजूदा गियर

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

7.3.11.2. दिन रात मोड

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

7.3.11.3. ड्राइविंग की स्थिति

यह ज़रूरी शर्त अब काम नहीं करती.

7.3.11.4. व्हील की स्पीड

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

7.3.11.5. पार्किंग ब्रेक

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

7.3.12. पोज़ सेंसर

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

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

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

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

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

7.4.1. टेलीफ़ोनी

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

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

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

  • [C-1-1] टेक्नोलॉजी के मुताबिक, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.
  • [C-1-2] इस टेक्नोलॉजी के लिए, एपीआई को पूरी तरह से सपोर्ट करना ज़रूरी है.

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

  • [C-2-1] सभी एपीआई को नो-ऑपरेशन के तौर पर लागू करना ज़रूरी है.
7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करना

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

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

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

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

  • [सी-एसआर] का सुझाव दिया जाता है, ताकि उपयोगकर्ता को यह सूचना दी जा सके कि इनकमिंग कॉल का जवाब देने से मौजूदा कॉल छूट जाएगा.

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

  • [C-SR] का इस बात पर बहुत ध्यान दिया जाता है कि उस डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड किया जाए जो अपने कॉल लॉग में कॉल लॉग एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखाता है. ऐसा तब होता है, जब तीसरे पक्ष का ऐप्लिकेशन अपने PhoneAccount पर, EXTRA_LOG_SELF_MANAGED_CALLS की अतिरिक्त कुंजी को true पर सेट करता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] पासपॉइंट से जुड़े WifiManager एपीआई को लागू करना ज़रूरी है, जैसा कि SDK टूल के दस्तावेज़ में बताया गया है.
  • [C-1-2] ज़रूरी है कि यह IEEE 802.11u स्टैंडर्ड के साथ काम करता हो. यह स्टैंडर्ड, खास तौर पर, नेटवर्क डिस्कवरी और सेलेक्शन से जुड़ा है. जैसे, जेनरिक ऐडवर्टाइज़मेंट सर्विस (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).

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

  • [C-2-1] पासपॉइंट से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException देना ज़रूरी है.
7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई से यात्रा का समय - आरटीटी)

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

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

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

7.4.3. ब्लूटूथ

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

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

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

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

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

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

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

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

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

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

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

  • इसमें कम से कम चार स्लॉट वाले एक से ज़्यादा विज्ञापन दिखाए जा सकते हैं.

  • [SR] रिज़ॉल्व किए जा सकने वाले निजी पते (आरपीए) का टाइम आउट 15 मिनट से ज़्यादा न लागू करने का सुझाव दिया जाता है. साथ ही, उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, टाइम आउट पर पते को रोटेट करें.

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

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

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

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

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

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

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

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

  • [C-1-3] पीयर-टू-पीयर स्टैंडर्ड और प्रोटोकॉल की मदद से, डेटा भेजने और पाने में सक्षम होना ज़रूरी है:

    • आईएसओ 18092
    • LLCP 1.2 (एनएफ़सी फ़ोरम के मुताबिक)
    • SDP 1.0 (एनएफ़सी फ़ोरम के मुताबिक)
    • एनडीईएफ़ पुश प्रोटोकॉल
    • SNEP 1.0 (एनएफ़सी फ़ोरम की ओर से तय किया गया)
  • [C-1-4] Android बीम के लिए काम करना ज़रूरी है और डिफ़ॉल्ट रूप से 'Android बीम' चालू करना चाहिए.
  • [C-1-5] जब Android बीम चालू हो या मालिकाना हक वाला कोई दूसरा एनएफ़सी P2p मोड चालू हो, तो यह ज़रूरी है कि वह Android बीम का इस्तेमाल करके मैसेज भेज या पा सके.
  • [C-1-6] SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट SNEP सर्वर से मिलने वाले मान्य NDEF मैसेज को android.nfc.ACTION_NDEF_DISCOVERED इंटेंट का इस्तेमाल करके ऐप्लिकेशन पर भेजना ज़रूरी है. सेटिंग में Android बीम को बंद करने के बाद, आने वाले NDEF मैसेज का डिस्पैच बंद नहीं किया जाना चाहिए.
  • [C-1-7] एनएफ़सी की शेयर करने की सेटिंग दिखाने के लिए, android.settings.NFCSHARING_SETTINGS के इंटेंट का पालन करना ज़रूरी है.
  • [C-1-8] एनपीपी सर्वर को लागू करना ज़रूरी है. NPP सर्वर को मिलने वाले मैसेज को SNEP के डिफ़ॉल्ट सर्वर की तरह ही प्रोसेस किया जाना चाहिए.
  • [C-1-9] SNEP क्लाइंट को लागू करना और Android बीम के चालू होने पर, आउटबाउंड P2P NDEF को डिफ़ॉल्ट SNEP सर्वर पर भेजने की कोशिश करना ज़रूरी है. अगर कोई डिफ़ॉल्ट SNEP सर्वर नहीं मिलता है, तो क्लाइंट को NPP सर्वर पर भेजने की कोशिश करनी होगी.
  • [C-1-10] android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback, और android.nfc.NfcAdapter.enableForegroundNdefPush का इस्तेमाल करके, आउटबाउंड P2P NDEF मैसेज सेट करने के लिए, फ़ोरग्राउंड गतिविधियों की अनुमति देनी होगी.
  • आउटबाउंड P2P NDEF मैसेज भेजने से पहले, हाथ के जेस्चर या स्क्रीन पर पुष्टि, जैसे कि 'बीम करने के लिए छुएं' का इस्तेमाल करना चाहिए.
  • [C-1-11] अगर डिवाइस, ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल के साथ काम करता है, तो एनएफ़सी कनेक्शन को ब्लूटूथ पर ट्रांसफ़र करने की सुविधा ज़रूरी है.
  • [C-1-12] एनएफ़सी फ़ोरम की ओर से, “Connection Handover वर्शन 1.2” और “ब्लूटूथ सिक्योर पेयरिंग एनएफ़सी वर्शन 1.0” एट्रिब्यूट को लागू करके, android.nfc.NfcAdapter.setBeamPushUris का इस्तेमाल करते समय ब्लूटूथ को कनेक्शन हैंडओवर करने की सुविधा दी जानी चाहिए. इस तरह के लागू करने के लिए एनएफ़सी पर हैंडओवर के अनुरोध/चुनने के रिकॉर्ड की अदला-बदली करने के लिए, हैंडओवर LLCP सेवा को “urn:nfc:sn:handover” सेवा को लागू करना होगा. साथ ही, ब्लूटूथ के असल डेटा को ट्रांसफ़र करने के लिए, ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल का इस्तेमाल करना होगा. लेगसी वजहों (Android 4.1 डिवाइसों के साथ काम करना जारी रखने के लिए) से, लागू करने की प्रोसेस को अब भी एनएफ़सी पर हैंडओवर अनुरोध/चुनने के रिकॉर्ड की अदला-बदली करने के लिए, SNEP GET अनुरोधों को स्वीकार करना चाहिए. हालांकि, लागू करने की प्रक्रिया में, कनेक्शन हैंडओवर करने के लिए SNEP GET अनुरोध नहीं भेजने चाहिए.
  • [C-1-13] एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
  • जब डिवाइस चालू हो और स्क्रीन चालू हो और लॉक-स्क्रीन अनलॉक हो, तो एनएफ़सी डिस्कवरी मोड का इस्तेमाल करना चाहिए.
  • यह ज़रूरी है कि Thin रफ़्तार के एनएफ़सी बारकोड प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदले गए हों) को पढ़ा जा सके.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] ईथरनेट पर ड्यूअल-स्टैक ऑपरेशन की सुविधा ज़रूरी है.

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

  • मोबाइल नेटवर्क पर आईपीवी6 ऑपरेशन (सिर्फ़ IPv6 और ड्यूअल-स्टैक) पर काम करना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू देनी होगी
  • [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.
  • [C-2-3] ज़रूरी है कि आपके पास कोई ऐसी गतिविधि हो जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को हैंडल करती हो, लेकिन उसे नो-ऑप के तौर पर लागू किया जा सकता हो.

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

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

  • [C-1-1] android.se.omapi.SEService.getReaders() तरीके को कॉल करने पर, उपलब्ध सुरक्षा एलिमेंट रीडर की गिनती करना ज़रूरी है.

7.5. कैमरे

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • इसमें बाहरी कैमरे के साथ काम करने की सुविधा हो सकती है, जो ज़रूरी नहीं है कि हमेशा कनेक्ट हो.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] ऐप्लिकेशन में शेयर किया जाने वाला स्टोरेज ज़रूर ऑफ़र करना चाहिए. इसे अक्सर "शेयर किया गया एक्सटर्नल स्टोरेज", "ऐप्लिकेशन का शेयर किया गया स्टोरेज" या उस Linux पाथ "/sdcard" से भी कहा जाता है जिस पर यह माउंट किया गया है.
  • [C-0-2] शेयर किए गए ऐसे स्टोरेज को कॉन्फ़िगर करना ज़रूरी है जो डिफ़ॉल्ट रूप से माउंट किया गया हो.इसे दूसरे शब्दों में "अलग-अलग तरह से" भी बताया जाना चाहिए. भले ही, स्टोरेज को डिवाइस के स्टोरेज कॉम्पोनेंट में इस्तेमाल किया गया हो या हटाए जा सकने वाले स्टोरेज मीडियम (जैसे, सुरक्षित डिजिटल कार्ड स्लॉट).
  • [C-0-3] ऐप्लिकेशन के शेयर किए गए स्टोरेज को सीधे Linux पाथ sdcard पर माउंट करना ज़रूरी है या sdcard से लेकर असल माउंट पॉइंट तक, Linux सिंबल वाला लिंक शामिल करना होगा.
  • [C-0-4] SDK टूल में बताए गए, शेयर किए गए इस स्टोरेज के लिए, android.permission.WRITE_EXTERNAL_STORAGE की अनुमति को लागू करना ज़रूरी है. शेयर किए गए स्टोरेज को ऐसे किसी भी ऐप्लिकेशन के लिए लिखने लायक होना चाहिए जिसे अनुमति ली गई है.

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

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

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

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

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

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

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

  • [C-2-1] सिर्फ़ पहले से इंस्टॉल किए गए और खास अधिकार वाले ऐसे Android ऐप्लिकेशन को ही अनुमति देनी चाहिए जिनके पास WRITE_EXTERNAL_STORAGE को सेकंडरी बाहरी स्टोरेज में सेव करने की अनुमति हो. ऐसा सिर्फ़ तब नहीं किया जा सकता, जब ऐप्लिकेशन के लिए खास तौर पर बनाई गई डायरेक्ट्री या URI में, ACTION_OPEN_DOCUMENT_TREE इंटेंट को ट्रिगर करके उसका इस्तेमाल किया गया हो.

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

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

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

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

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

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

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

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

7.7. यूएसबी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

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

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

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

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

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

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

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

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

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

इस सेक्शन में, "आउटपुट पोर्ट" एक फ़िज़िकल इंटरफ़ेस है. जैसे, 3.5 मि॰मी॰ का ऑडियो जैक, एचडीएमआई या यूएसबी ऑडियो क्लास वाला यूएसबी होस्ट मोड पोर्ट. ब्लूटूथ, वाई-फ़ाई या मोबाइल नेटवर्क जैसे रेडियो-आधारित प्रोटोकॉल पर ऑडियो आउटपुट के लिए, "आउटपुट पोर्ट" शामिल नहीं किया जा सकता.

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

Android नेटवर्क में 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करके, हेडसेट और दूसरी ऑडियो ऐक्सेसरी के साथ काम करने के लिए, अगर डिवाइस में एक या उससे ज़्यादा ऐनालॉग ऑडियो पोर्ट शामिल हैं, तो ये काम किए जा सकते हैं:

  • [C-SR] 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक बनाने के लिए, कम से कम एक ऑडियो पोर्ट को शामिल करने का सुझाव दिया जाता है.

अगर लागू किए जाने वाले डिवाइस में 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक है, तो वे:

  • [C-1-1] माइक्रोफ़ोन वाले स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाया जा सकता है.
  • [C-1-2] सीटीआईए पिन-आउट ऑर्डर के साथ, टीआरआरएस के ऑडियो प्लग के साथ काम करना ज़रूरी है.
  • [C-1-3] ऑडियो प्लग पर दिए गए माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, नीचे दी गई तीन रेंज के, कीकोड की पहचान करने और उन्हें मैप करने की सुविधा दी जानी चाहिए:
    • 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
    • 210-290 ओम: KEYCODE_VOLUME_UP
    • 360-680 ओम: KEYCODE_VOLUME_DOWN
  • [C-1-4] प्लग इन्स डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है. हालांकि, यह ज़रूरी है कि प्लग पर लगे सभी संपर्क, जैक पर अपने ज़रूरी सेगमेंट को छू रहे हों.
  • [C-1-5] 32 ओम वाले स्पीकर प्रतिरोध पर कम से कम 150mV ± 10% आउटपुट वोल्टेज तक चलाने में सक्षम होना चाहिए.
  • [C-1-6] माइक्रोफ़ोन बायस वोल्टेज 1.8V ~ 2.9V के बीच होना चाहिए.
  • [C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, नीचे दिए गए उदाहरण के हिसाब से, कीकोड का पता लगाकर उसे मैप करना ज़रूरी है:
    • 110-180 ओम: KEYCODE_VOICE_ASSIST
  • [C-SR] ओएमटीपी पिन-आउट ऑर्डर के साथ ऑडियो प्लग के साथ काम करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
  • [C-SR] माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्डिंग करने की ज़बरदस्ती सलाह दी जाती है.

अगर लागू होने वाले डिवाइस में 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक है और उसमें माइक्रोफ़ोन काम करता है, तो वह android.intent.action.HEADSET_PLUG को ब्रॉडकास्ट करता है कि अतिरिक्त वैल्यू वाले माइक्रोफ़ोन को 1 पर सेट किया गया हो, तो:

  • [C-2-1] ज़रूरी है कि प्लग-इन की गई ऑडियो ऐक्सेसरी में माइक्रोफ़ोन का पता लगाया जा सके.

7.8.3. नियर-अल्ट्रासाउंड

नियर-अल्ट्रासाउंड ऑडियो का बैंडविथ 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ का बैंड होता है.

डिवाइस पर यह सुविधा लागू करना:

  • नियर-अल्ट्रासाउंड ऑडियो की क्षमता के बारे में सही तरीके से रिपोर्ट करना ज़रूरी है. इसके लिए, AudioManager.getproperty एपीआई का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को ये ज़रूरी शर्तें पूरी करनी होंगी:

  • [C-1-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बैंड में माइक्रोफ़ोन का औसत पावर रिस्पॉन्स, 2 किलोहर्ट्ज़ पर प्रतिक्रिया के समय से 15 dB से कम नहीं होना चाहिए.
  • [C-1-2] -26 डीबीएफ़एस पर 19 किलोहर्ट्ज़ के टोन के लिए, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ से ज़्यादा के नॉइज़ रेशियो के लिए, माइक्रोफ़ोन के अनवेटेड सिग्नल का सिग्नल 50 डीबी से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND का मान "सही" है, तो:

  • [C-2-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ में स्पीकर की औसत प्रतिक्रिया, 2 किलोहर्ट्ज़ पर प्रतिक्रिया के समय से 40 dB से कम नहीं होनी चाहिए.

7.9. आभासी वास्तविकता

Android में "वर्चुअल रिएलिटी" (वीआर) ऐप्लिकेशन बनाने के लिए एपीआई और सुविधाएं शामिल हैं. इनमें अच्छी क्वालिटी वाले मोबाइल वीआर अनुभव भी शामिल हैं. डिवाइस पर इन एपीआई और सुविधाओं को सही तरीके से लागू करना ज़रूरी है. इसके बारे में इस सेक्शन में बताया गया है.

7.9.1. वर्चुअल रिएलिटी मोड

Android में वीआर मोड की सुविधा काम करती है. यह एक ऐसी सुविधा है जो सूचनाओं की स्टीरियोस्कोपिक रेंडरिंग को मैनेज करती है. साथ ही, वीआर ऐप्लिकेशन में उपयोगकर्ता के फ़ोकस को ध्यान में रखते हुए, मोनोक्युलर सिस्टम के यूज़र इंटरफ़ेस (यूआई) के कॉम्पोनेंट बंद कर देती है.

7.9.2. वर्चुअल रिएलिटी मोड - बेहतर परफ़ॉर्मेंस

अगर लागू किए गए डिवाइस पर वीआर मोड काम करता है, तो वे:

  • [C-1-1] कम से कम दो फ़िज़िकल कोर होने चाहिए.
  • [C-1-2] android.hardware.vr.high_performance सुविधा के बारे में एलान करना ज़रूरी है.
  • [C-1-3] स्थायी परफ़ॉर्मेंस मोड के साथ काम करना ज़रूरी है.
  • [C-1-4] OpenGL ES 3.2 के साथ काम करना ज़रूरी है.
  • [C-1-5] android.hardware.vulkan.level 0 के साथ काम करना ज़रूरी है.
  • android.hardware.vulkan.level 1 या इसके बाद के वर्शन के साथ काम करना चाहिए.
  • [C-1-6] EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace को लागू करना ज़रूरी है. साथ ही, एक्सटेंशन को उपलब्ध EGL एक्सटेंशन की सूची में दिखाना ज़रूरी है.
  • [C-1-8] GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures को लागू करना ज़रूरी है. साथ ही, एक्सटेंशन को उपलब्ध GL एक्सटेंशन की सूची में दिखाना ज़रूरी है.
  • [C-SR] का खास तौर पर सुझाव दिया जाता है कि GL_EXT_external_buffer, GL_EXT_EGL_image_array को लागू किया जाए, और एक्सटेंशन को उपलब्ध जीएल एक्सटेंशन की सूची में दिखाया जाए.
  • [C-SR] का सुझाव दिया जाता है, ताकि Vulkan 1.1 के साथ काम किया जा सके.
  • [C-SR] VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image को लागू करने का सुझाव दिया जाता है. साथ ही, इन्हें Vulkan एक्सटेंशन की सूची में शामिल करके दिखाया जाता है.
  • [सी-एसआर] इस बात का सुझाव दिया जाता है कि कम से कम एक वुल्कन सूची में परिवार के सभी सदस्यों को दिखाया जाए. इसमें flags में VK_QUEUE_GRAPHICS_BIT और VK_QUEUE_COMPUTE_BIT, और queueCount, दोनों की संख्या कम से कम दो होनी चाहिए.
  • [C-1-7] जीपीयू और डिसप्ले के लिए, शेयर किए गए फ़्रंट बफ़र का ऐक्सेस इस तरह सिंक होना चाहिए कि 60fps पर वीआर कॉन्टेंट की बारी-बारी से रेंडर होने की सुविधा के साथ दो रेंडर करने के तरीके दिखाए जाएंगे.
  • [C-1-9] एनडीके में बताए गए तरीके के मुताबिक, AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT फ़्लैग के लिए काम करना ज़रूरी है.
  • [C-1-10] कम से कम इन फ़ॉर्मैट के लिए, AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT जैसे इस्तेमाल फ़्लैग के साथ AHardwareBuffer के लिए काम करना ज़रूरी है: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
  • [C-SR] का सुझाव खास तौर पर दिया जाता है, ताकि C-1-10 में एक से ज़्यादा लेयर और फ़्लैग और फ़ॉर्मैट वाली AHardwareBuffer फ़ाइलें असाइन की जा सकें.
  • [C-1-11] 30fps पर कम से कम 3840 x 2160 H.264 को डिकोड करने की सुविधा होनी चाहिए, जो औसतन 40 एमबीपीएस (30 FPS-10 एमबीपीएस पर 1920 x1080 के चार इंस्टेंस के बराबर या 1920 x 20 एमबीपीएस-1920 x 20 एमबीपीएस के 2 इंस्टेंस पर) हो.
  • [C-1-12] HEVC और VP9 की सुविधा होनी चाहिए. साथ ही, 10 एमबीपीएस के औसत कंप्रेस किए हुए 30 FPS (फ़्रेम प्रति सेकंड) पर, कम से कम 1920 x 1080 को डिकोड करने की सुविधा होनी चाहिए. साथ ही, 30 x 2160 FPS (फ़्रेम प्रति सेकंड) के बराबर या 10 एमबीपीएस के 10 एमबीपीएस के बराबर, 3840 x 2160 को डिकोड करना ज़रूरी है.
  • [C-1-13] HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना ज़रूरी है और त्वचा के तापमान की सटीक वैल्यू दिखाना.
  • [C-1-14] इसमें एम्बेड की गई स्क्रीन होनी चाहिए और इसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
  • [C-SR] का खास तौर पर सुझाव दिया जाता है कि डिसप्ले रिज़ॉल्यूशन कम से कम 2560 x 1440 हो.
  • [C-1-15] VR मोड में होने पर, डिसप्ले को कम से कम 60 हर्ट्ज़ पर अपडेट करना ज़रूरी है.
  • [C-1-17] डिसप्ले को लो-परसिस्टेंस मोड के साथ काम करना चाहिए और उसे 5 मिलीसेकंड तक बनाए रखना चाहिए. परसिस्टेंस को इससे पता चलता है कि किसी पिक्सल से कितनी देर तक रोशनी निकल रही है.
  • [C-1-18] ब्लूटूथ 4.2 और ब्लूटूथ LE डेटा लेंथ एक्सटेंशन सेक्शन 7.4.3 के साथ काम करना ज़रूरी है.
  • [C-1-19] यहां दिए गए सभी डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप के साथ काम करना और उसके बारे में सही तरीके से रिपोर्ट करना ज़रूरी है:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] का सुझाव दिया जाता है कि ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप के साथ काम किया जा सके.
  • [C-1-21] android.hardware.hifi_sensors के लिए जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इसके बारे में सेक्शन 7.3.9 में बताया गया है.
  • [सी-एसआर] का सुझाव दिया जाता है, ताकि android.hardware.sensor.hifi_sensors सुविधा के साथ काम किया जा सके.
  • [C-1-22] फ़ोटॉन के इंतज़ार का समय 28 मिलीसेकंड से ज़्यादा नहीं होना चाहिए.
  • [C-SR] इस बात पर ज़ोर दिया जाता है कि फ़ोटॉन की इंतज़ार के समय पर एंड-टू-एंड मोशन हो, जो 20 मिलीसेकंड से ज़्यादा न हो.
  • [C-1-23] पहले फ़्रेम का अनुपात होना ज़रूरी है. यह काले से सफ़ेद रंग में ट्रांज़िशन के बाद, पहले फ़्रेम पर पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का अनुपात होता है. यह कम से कम 85% होता है.
  • [सी-एसआर] का सुझाव दिया जाता है कि पहले फ़्रेम का अनुपात कम से कम 90% रखें.
  • इसमें फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर उपलब्ध कराया जा सकता है. साथ ही, Process.getExclusiveCores API की सुविधा दी जा सकती है, ताकि सबसे ज़्यादा इस्तेमाल किए जाने वाले फ़ोरग्राउंड ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दी जा सके.

अगर खास कोर काम करता है, तो कोर:

  • [C-2-1] इस पर किसी और यूज़रस्पेस प्रोसेस को चलाने की अनुमति नहीं देनी चाहिए (ऐप्लिकेशन में इस्तेमाल किए जाने वाले डिवाइस ड्राइवर को छोड़कर), लेकिन ज़रूरत के मुताबिक कुछ कर्नेल प्रोसेस को चलाने की अनुमति दे सकते हैं.

8. परफ़ॉर्मेंस और पावर

उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, परफ़ॉर्मेंस और बेहतर परफ़ॉर्मेंस से जुड़ी कुछ ज़रूरी शर्तें अहम होती हैं. इनसे, ऐप्लिकेशन डेवलप करते समय डेवलपर के बुनियादी अनुमान पर असर पड़ता है.

8.1. उपयोगकर्ता अनुभव को लगातार बनाए रखना

अगर ऐप्लिकेशन और गेम के लिए, फ़्रेम रेट और रिस्पॉन्स में लगने वाले समय को एक जैसा बनाए रखने के लिए कुछ ज़रूरी शर्तें तय की गई हों, तो असली उपयोगकर्ता को एक बेहतर यूज़र इंटरफ़ेस उपलब्ध कराया जा सकता है. डिवाइस टाइप के आधार पर, डिवाइस पर सुविधाएं लागू करने से जुड़ी ज़रूरी शर्तें हो सकती हैं. ये शर्तें, यूज़र इंटरफ़ेस के इंतज़ार के समय और टास्क स्विच करने से जुड़ी शर्तों को पूरा करती हैं. इन शर्तों के बारे में सेक्शन 2 में बताया गया है.

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टिशन) पर, फ़ाइल के ऐक्सेस से जुड़ी एक जैसी परफ़ॉर्मेंस के लिए एक समान बेसलाइन उपलब्ध कराना, ऐप्लिकेशन डेवलपर को उनके सॉफ़्टवेयर डिज़ाइन में मदद करने के लिए सही उम्मीदें करने में मदद करता है. डिवाइस टाइप के आधार पर, डिवाइस पर कुछ ज़रूरी शर्तें लागू हो सकती हैं. इन शर्तों के बारे में सेक्शन 2 में बताया गया है. इन शर्तों के बारे में यहां दिए गए 'पढ़ने और लिखने' से जुड़ी कार्रवाईयां की जा सकती हैं:

  • क्रम से लिखने के लिए परफ़ॉर्मेंस. 10 एमबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखकर मेज़र की गई.
  • रैंडम तरीके से लिखने की परफ़ॉर्मेंस. इसे मापने के लिए, 4 केबी राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी गई.
  • क्रम से पढ़ने की परफ़ॉर्मेंस. 10 एमबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर इसका आकलन किया जाता है.
  • किसी भी क्रम में पढ़ने की परफ़ॉर्मेंस. 4 केबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर मापा जाता है.

8.3. पावर सेविंग मोड

अगर एओएसपी में शामिल डिवाइस पावर मैनेजमेंट को बेहतर बनाने के लिए, डिवाइस लागू करने के तरीकों में सुविधाएं शामिल हैं, तो वे:

  • [C-1-1] ट्रिगर करने, रखरखाव करने, वेकअप एल्गोरिदम, और ऐप स्टैंडबाय और बैटरी बचाने वाले मोड की ग्लोबल सिस्टम सेटिंग के इस्तेमाल के लिए एओएसपी को लागू करने से अलग नहीं होना चाहिए.
  • [C-1-2] ऐप्लिकेशन स्टैंडबाय मोड के लिए, हर बकेट में ऐप्लिकेशन के लिए जॉब, अलार्म, और नेटवर्क की थ्रॉटलिंग को मैनेज करने के लिए, ग्लोबल सेटिंग का इस्तेमाल करने के लिए एओएसपी को लागू करने के तरीके में बदलाव नहीं करना चाहिए.
  • [C-1-3] ऐप्लिकेशन स्टैंडबाय के लिए इस्तेमाल किए जाने वाले ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, एओएसपी लागू करने के तरीके में बदलाव नहीं करना चाहिए.
  • [C-1-4] पावर मैनेजमेंट में बताए गए तरीके से, ऐप्लिकेशन स्टैंडबाय बकेट और बैटरी सेवर मोड को लागू करना ज़रूरी है.
  • [C-1-5] जब डिवाइस पावर सेव मोड पर हो, तब PowerManager.isPowerSaveMode() के लिए true दिखाना होगा.
  • [सी-एसआर] का सुझाव दिया जाता है, ताकि बैटरी सेवर की सुविधा को चालू और बंद करने के लिए, उपयोगकर्ता को अधिकार दिया जा सके.
  • [C-SR] लोगों को उन सभी ऐप्लिकेशन को दिखाने का अधिकार देने के लिए बहुत ज़्यादा सुझाव दिया जाता है जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड से छूट दी गई है.

पावर बचाने वाले मोड के अलावा, Android डिवाइस को लागू करने के लिए बेहतर कॉन्फ़िगरेशन और पावर इंटरफ़ेस (एसीपीआई) के मुताबिक, स्लीप मोड (कम बैटरी मोड) की चार में से कोई भी या सभी स्थितियां लागू की जा सकती हैं.

अगर एसीपीआई के हिसाब से डिवाइस लागू करने के लिए S4 पावर स्टेट लागू किए जाते हैं, तो वे:

  • [C-1-1] इस स्थिति में, उपयोगकर्ता ने डिवाइस को बंद करने के लिए कोई खास कार्रवाई की हो. उदाहरण के लिए, डिवाइस के किसी हिस्से की लिड बंद करना या वाहन या टेलीविज़न को बंद करना. साथ ही, डिवाइस को दोबारा चालू करने से पहले (उदाहरण के लिए, लिड को खोलना या वाहन या टेलीविज़न को वापस चालू करना).

अगर एसीपीआई के हिसाब से डिवाइस लागू करने के लिए S3 पावर स्टेट लागू किए जाते हैं, तो वे:

  • [C-2-1] ऊपर दिए गए C-1-1 के मुताबिक होना ज़रूरी है या S3 स्टेटस सिर्फ़ तब डालना होगा, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम के संसाधनों (जैसे कि स्क्रीन, सीपीयू) की ज़रूरत न हो.

    इसके उलट, इस SDK टूल में बताए गए तरीके के मुताबिक, तीसरे पक्ष के ऐप्लिकेशन को सिस्टम संसाधनों की ज़रूरत पड़ने पर, S3 वाले स्टेटस से बाहर निकलना होगा.

    उदाहरण के लिए, तीसरे पक्ष के ऐप्लिकेशन FLAG_KEEP_SCREEN_ON से स्क्रीन को चालू रखने या PARTIAL_WAKE_LOCK तक सीपीयू को चलाने का अनुरोध करते हैं, लेकिन डिवाइस को S3 स्थिति में तब तक नहीं डालना चाहिए, जब तक कि C-1-1 में दी गई जानकारी के मुताबिक, उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्थिति में रखने के लिए साफ़ तौर पर कोई कार्रवाई न की हो. वहीं, जब JobScheduler की मदद से तीसरे पक्ष के ऐप्लिकेशन से कोई टास्क ट्रिगर किया जाता है या Firebase क्लाउड से मैसेज, तीसरे पक्ष के ऐप्लिकेशन को डिलीवर किया जाता है, तो डिवाइस को S3 स्थिति से बाहर निकलना होगा. ऐसा तब करना होगा, जब उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्थिति में न रखा हो. ये ऐसे उदाहरण नहीं हैं जिनमें दी गई जानकारी पूरी नहीं होती. एओएसपी, स्क्रीन चालू करने के ऐसे बड़े सिग्नल लागू करता है जो इस स्थिति से स्क्रीन चालू करते हैं.

8.4. पावर कंज़म्पशन अकाउंटिंग

ऊर्जा की खपत का ज़्यादा सटीक हिसाब और रिपोर्टिंग से ऐप्लिकेशन डेवलपर को फ़ायदे मिलते हैं. साथ ही, ऐप्लिकेशन में इस्तेमाल होने वाली ऊर्जा के इस्तेमाल के पैटर्न को ऑप्टिमाइज़ करने के लिए टूल भी मिलते हैं.

डिवाइस पर यह सुविधा लागू करना:

  • [SR] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देने का बहुत ज़्यादा सुझाव दिया जाता है. यह प्रोफ़ाइल हर हार्डवेयर कॉम्पोनेंट के लिए इस्तेमाल की जाने वाली मौजूदा वैल्यू के बारे में बताती है. साथ ही, समय के साथ कॉम्पोनेंट की वजह से बैटरी के तेज़ी से खर्च होने की अनुमानित जानकारी भी दी जाती है, जैसा कि Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [SR] ऊर्जा खपत की सभी वैल्यू, मिलीयम्परे घंटे (mAh) में रिपोर्ट करने का सुझाव दिया जाता है.
  • [SR] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू बिजली की खपत की रिपोर्ट करने का सुझाव दिया जाता है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल के लागू होने की ज़रूरी शर्तों को पूरा करता है.
  • [SR] का सुझाव दिया जाता है कि ऐप्लिकेशन डेवलपर को adb shell dumpsys batterystats शेल कमांड के ज़रिए, बैटरी के इस इस्तेमाल की जानकारी उपलब्ध कराई जाए.
  • अगर किसी ऐप्लिकेशन के लिए, हार्डवेयर कॉम्पोनेंट पावर के इस्तेमाल की जानकारी नहीं दी जा सकती, तो इसे खुद हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.

8.5. एक ही तरह की परफ़ॉर्मेंस

लंबे समय तक चलने वाले बेहतरीन ऐप्लिकेशन की परफ़ॉर्मेंस में बहुत ज़्यादा उतार-चढ़ाव हो सकता है. ऐसा, बैकग्राउंड में चल रहे दूसरे ऐप्लिकेशन या तापमान की सीमाओं की वजह से सीपीयू के थ्रॉटल होने की वजह से हो सकता है. Android में प्रोग्राम के हिसाब से, प्रोग्रैम्ड तरीके से काम करने वाले इंटरफ़ेस शामिल हैं. इससे, जब डिवाइस पर यह सुविधा काम करती है, तब सबसे ऊपर वाला फ़ोरग्राउंड ऐप्लिकेशन यह अनुरोध कर सकता है कि सिस्टम, संसाधनों के बंटवारे को ऑप्टिमाइज़ करे, ताकि इस तरह के उतार-चढ़ाव से बचा जा सके.

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] PowerManager.isSustainedPerformanceModeSupported() एपीआई वाले तरीके का इस्तेमाल करके, लगातार परफ़ॉर्मेंस बनाए रखने वाले मोड के साथ काम करने की सटीक जानकारी देना ज़रूरी है.

  • इसमें लगातार परफ़ॉर्मेंस को बनाए रखने वाला मोड भी काम करना चाहिए.

अगर डिवाइस लागू करने की सुविधा, लगातार परफ़ॉर्मेंस मोड पर काम करने के बारे में रिपोर्ट करती है, तो वे:

  • [C-1-1] ऐप्लिकेशन के लिए अनुरोध करने पर, सबसे ऊपर वाले फ़ोरग्राउंड ऐप्लिकेशन को कम से कम 30 मिनट तक परफ़ॉर्मेंस का एक जैसा लेवल देना ज़रूरी है.
  • [C-1-2] Window.setSustainedPerformanceMode() एपीआई और उससे जुड़े अन्य एपीआई का पालन करना ज़रूरी है.

अगर लागू करने वाले डिवाइस में दो या उससे ज़्यादा सीपीयू कोर शामिल हैं, तो वे:

  • कम से कम एक ऐसा खास कोर होना चाहिए जिसे सबसे ऊपर वाले फ़ोरग्राउंड ऐप्लिकेशन से रिज़र्व किया जा सके.

अगर लागू किए गए डिवाइस पर, टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर रिज़र्व किया जाता है, तो ये काम किए जा सकते हैं:

  • [C-2-1] Process.getExclusiveCores() एपीआई वाले तरीके का इस्तेमाल करके, उन खास कोर के आईडी नंबर को रिपोर्ट करना ज़रूरी है जिन्हें सबसे ऊपर दिखने वाले ऐप्लिकेशन के ज़रिए रिज़र्व किया जा सकता है.
  • [C-2-2] ऐप्लिकेशन में खास कोर पर चलाने के लिए इस्तेमाल किए जाने वाले डिवाइस ड्राइवर के अलावा किसी उपयोगकर्ता स्पेस की प्रोसेस को अनुमति नहीं देनी चाहिए, लेकिन हो सकता है कि कुछ कर्नेल प्रोसेस को ज़रूरत के हिसाब से चलाया जा सके.

अगर डिवाइस पर लागू करने की सुविधा किसी खास कोर के साथ काम नहीं करती है, तो ये:

  • [C-3-1] Process.getExclusiveCores() एपीआई वाले तरीके का इस्तेमाल करके, आपको एक खाली सूची देनी होगी.

9. सिक्योरिटी मॉडल के साथ काम करने की सुविधा

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] Android डेवलपर दस्तावेज़ में एपीआई के सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ के मुताबिक, Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के हिसाब से सुरक्षा मॉडल लागू करना ज़रूरी है.

  • [C-0-2] खुद हस्ताक्षर किए गए ऐप्लिकेशन को इंस्टॉल करने की सुविधा दी जानी चाहिए. इसके लिए, किसी तीसरे पक्ष या संस्था से किसी अन्य अनुमति/सर्टिफ़िकेट की ज़रूरत नहीं होनी चाहिए. खास तौर पर, इस सुविधा के साथ काम करने वाले डिवाइसों को, यहां दिए गए सब-सेक्शन में बताए गए सुरक्षा तरीकों के साथ काम करना चाहिए.

9.1. अनुमतियां

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] Android डेवलपर दस्तावेज़ में बताए गए Android अनुमतियों के मॉडल के साथ काम करना ज़रूरी है. खास तौर पर, उन्हें SDK टूल के दस्तावेज़ में बताई गई हर अनुमति को लागू करना होगा. किसी भी अनुमति को छोड़ा, बदला या अनदेखा नहीं किया जा सकता.

  • अतिरिक्त अनुमतियां जोड़ी जा सकती हैं, बशर्ते अनुमति आईडी की नई स्ट्रिंग android.\* नेमस्पेस में न हों.

  • [C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ(पाथों) में पहले से इंस्टॉल किए गए हों. साथ ही, यह हर ऐप्लिकेशन के लिए साफ़ तौर पर अनुमति वाली अनुमतियों के सबसेट में शामिल हों. एओएसपी को लागू करने के लिए, यह ज़रूरी शर्त पूरी की जाती है. इसके लिए, etc/permissions/ पाथ में मौजूद फ़ाइलों से हर ऐप्लिकेशन के लिए, अनुमति वाली अनुमतियों को पढ़ें और उनके हिसाब से अनुमतियां दें. इसके अलावा, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करें.

रनटाइम में उपयोगकर्ताओं को मिलने वाली अनुमतियां वे होती हैं जिनमें सुरक्षा के लेवल खतरनाक के तौर पर मार्क किया गया हो. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान इनका अनुरोध करते हैं.

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना होगा, ताकि यह तय किया जा सके कि अनुरोध की गई रनटाइम की अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम की अनुमतियां मैनेज करने के लिए इंटरफ़ेस भी देना है.
  • [C-0-4] दोनों यूज़र इंटरफ़ेस को एक ही बार लागू करना ज़रूरी है.
  • [C-0-5] पहले से इंस्टॉल किए गए ऐप्लिकेशन को रनटाइम की अनुमति तब तक नहीं देनी चाहिए, जब तक:
    • ऐप्लिकेशन का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ली जा सकती है.
    • रनटाइम की अनुमतियां ऐसे इंटेंट पैटर्न से जुड़ी होती हैं जिसके लिए पहले से इंस्टॉल किया गया ऐप्लिकेशन, डिफ़ॉल्ट हैंडलर के तौर पर सेट होता है.
  • [C-0-6] सिर्फ़ उन सिस्टम ऐप्लिकेशन को android.permission.RECOVER_KEYSTORE की अनुमति देनी होगी जिन्होंने ठीक से सुरक्षित रिकवरी एजेंट रजिस्टर किया है. सही तरीके से सुरक्षित रिकवरी एजेंट को डिवाइस में मौजूद ऐसा सॉफ़्टवेयर एजेंट कहा जाता है जो डिवाइस के रिमोट स्टोरेज के साथ सिंक होता है. इसमें, Google Cloud Key Vault सेवा में बताई गई सुरक्षा के बराबर या उससे ज़्यादा मज़बूत सुरक्षा वाले हार्डवेयर होते हैं. ऐसा इसलिए होता है, ताकि लॉकस्क्रीन नॉलेज फ़ैक्टर पर ज़बरदस्ती हमले को रोका जा सके.

अगर किसी डिवाइस पर, पहले से इंस्टॉल किया गया ऐप्लिकेशन इस्तेमाल किया जा रहा है या तीसरे पक्ष के ऐप्लिकेशन को इस्तेमाल के आंकड़े ऐक्सेस करने की अनुमति देनी है, तो वे:

  • [SR] का खास तौर पर सुझाव दिया जाता है. हम android.permission.PACKAGE_USAGE_STATS की अनुमति का एलान करने वाले ऐप्लिकेशन के लिए, android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट के हिसाब से, इस्तेमाल के आंकड़ों का ऐक्सेस देने या रद्द करने का तरीका, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देते हैं.

अगर डिवाइस पर लागू होने वाले किसी भी ऐप्लिकेशन और पहले से इंस्टॉल किए गए ऐप्लिकेशन को इस्तेमाल के आंकड़े ऐक्सेस करने से रोकना है, तो:

  • [C-1-1] उपयोगकर्ता के पास अब भी ऐसी गतिविधि होनी चाहिए जो android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट पैटर्न को हैंडल करती हो. हालांकि, उसे नो-ऑप के तौर पर लागू करना ज़रूरी है. इसका मतलब यह है कि उपयोगकर्ता जब ऐक्सेस को अस्वीकार कर दिया जाए, तब भी वैसा ही व्यवहार किया जाना चाहिए.

9.2. यूआईडी और प्रोसेस आइसोलेशन

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] Android ऐप्लिकेशन के सैंडबॉक्स मॉडल के साथ काम करना चाहिए, जिसमें हर ऐप्लिकेशन एक यूनीक Unixstyle यूआईडी के तौर पर काम करता हो और यह एक अलग प्रोसेस में काम करता हो.
  • [C-0-2] इस नीति से, एक ही Linux यूज़र आईडी के तौर पर कई ऐप्लिकेशन चलाने की सुविधा मिलनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि ऐप्लिकेशन सही तरीके से साइन किए गए हों और उन्हें बनाए गए हों, जैसा कि सुरक्षा और अनुमतियों के रेफ़रंस में बताया गया है.

9.3. फ़ाइल सिस्टम अनुमतियां

डिवाइस पर यह सुविधा लागू करना:

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

डिवाइस पर Android की सुरक्षा और अनुमति के मॉडल को लागू करना ज़रूरी है. भले ही, उनमें ऐसा रनटाइम एनवायरमेंट शामिल हो जो डाल्विक एक्ज़िक्यूटेबल फ़ॉर्मैट या नेटिव कोड के बजाय, किसी दूसरे सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन एक्ज़ीक्यूट करता है. दूसरे शब्दों में:

  • [C-0-1] वैकल्पिक रनटाइम खुद ही Android ऐप्लिकेशन होने चाहिए. साथ ही, इन्हें सेक्शन 9 में बताए गए स्टैंडर्ड Android सुरक्षा मॉडल का पालन करना चाहिए.

  • [C-0-2] वैकल्पिक रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिनके लिए रनटाइम की AndroidManifest.xml फ़ाइल में अनुरोध नहीं की गई अनुमतियों के तहत सुरक्षित किया जाता है. ऐसा <uses-permission> तरीके से किया जाता है.

  • [C-0-3] वैकल्पिक रनटाइम में ऐप्लिकेशन को ऐसी सुविधाओं का इस्तेमाल करने की अनुमति नहीं दी जानी चाहिए जिन्हें सिस्टम ऐप्लिकेशन के लिए प्रतिबंधित Android अनुमतियों की मदद से सुरक्षित किया गया है.

  • [C-0-4] वैकल्पिक रनटाइम को Android सैंडबॉक्स मॉडल का पालन करना चाहिए और किसी वैकल्पिक रनटाइम का इस्तेमाल करके इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन के सैंडबॉक्स का फिर से इस्तेमाल नहीं करना चाहिए. हालांकि, शेयर किए गए यूज़र आईडी और साइनिंग सर्टिफ़िकेट के Android के स्टैंडर्ड तरीकों को छोड़कर.

  • [C-0-5] वैकल्पिक रनटाइम को अन्य Android ऐप्लिकेशन के सैंडबॉक्स के साथ लॉन्च नहीं किया जाना चाहिए, न देना चाहिए या न ही उन्हें ऐक्सेस दिया जाना चाहिए.

  • [C-0-6] वैकल्पिक रनटाइम को किसी सुपर उपयोगकर्ता (रूट) या किसी अन्य यूज़र आईडी के साथ लॉन्च किया जाना, अनुमति मिलना या अन्य ऐप्लिकेशन को कोई खास अधिकार नहीं देना चाहिए.

  • [C-0-7] जब वैकल्पिक रनटाइम की .apk फ़ाइलों को डिवाइस इंप्लिमेंटेशन की सिस्टम इमेज में शामिल किया जाता है, तो इसे किसी ऐसी कुंजी से साइन किया जाना चाहिए जो डिवाइस के साथ लागू होने वाले अन्य ऐप्लिकेशन पर साइन करने के लिए इस्तेमाल की जाने वाली कुंजी से अलग हो.

  • [C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, दूसरे रनटाइम को ऐप्लिकेशन में Android की जिन अनुमतियों का इस्तेमाल करना होता है उनके लिए उपयोगकर्ता की सहमति लेनी ज़रूरी है.

  • [C-0-9] जब किसी ऐप्लिकेशन को किसी ऐसे डिवाइस संसाधन का इस्तेमाल करने की ज़रूरत होती है जिसके लिए Android से जुड़ी अनुमति (जैसे कि कैमरा, GPS वगैरह) मौजूद हो, तो वैकल्पिक रनटाइम में उपयोगकर्ता को यह बताना ज़रूरी होता है कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर सकेगा.

  • [C-0-10] जब रनटाइम एनवायरमेंट, ऐप्लिकेशन की सुविधाओं को इस तरह से रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट में रनटाइम की शर्तों के हिसाब से सभी अनुमतियों की सूची होना ज़रूरी है. ऐसा रनटाइम का इस्तेमाल करके कोई ऐप्लिकेशन इंस्टॉल करते समय, रनटाइम के एनवायरमेंट में होना चाहिए.

  • वैकल्पिक रनटाइम में, PackageManager के ज़रिए ऐप्लिकेशन को अलग-अलग Android सैंडबॉक्स (Linux यूज़र आईडी वगैरह) में इंस्टॉल करना चाहिए.

  • वैकल्पिक रनटाइम एक ही Android सैंडबॉक्स दे सकते हैं, जिसे सभी ऐप्लिकेशन अन्य रनटाइम का इस्तेमाल करके शेयर करते हैं.

9.5. बहु-उपयोगकर्ता सहायता

Android में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता दी गई है. साथ ही, Android पर सभी उपयोगकर्ताओं को अलग-अलग कॉल करने की सुविधा भी मिलती है.

  • डिवाइस लागू हो सकता है, लेकिन अगर एक से ज़्यादा उपयोगकर्ता, मुख्य बाहरी स्टोरेज के लिए हटाए जा सकने वाले मीडिया का इस्तेमाल करते हैं, तो उन्हें इस सुविधा को चालू नहीं करना चाहिए.

अगर लागू किए जाने वाले डिवाइस में कई उपयोगकर्ता शामिल हैं, तो वे:

  • [C-1-1] एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता से जुड़ी इन ज़रूरी शर्तों को पूरा करना ज़रूरी है.
  • [C-1-2] हर उपयोगकर्ता के लिए ऐसा सुरक्षा मॉडल लागू करना ज़रूरी है जो एपीआई में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ के मुताबिक, Android प्लैटफ़ॉर्म के सिक्योरिटी मॉडल के मुताबिक हो.
  • [C-1-3] उपयोगकर्ता के हर इंस्टेंस के लिए, शेयर किए गए ऐप्लिकेशन स्टोरेज (यानी /sdcard) के लिए, अलग-अलग और अलग-अलग डायरेक्ट्री होनी चाहिए.
  • [C-1-4] ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाले और उसकी ओर से चलाए जा रहे ऐप्लिकेशन, किसी दूसरे उपयोगकर्ता के मालिकाना हक वाली फ़ाइलों की सूची न बना सकें, उन्हें पढ़ या उनमें लिख न सकें, भले ही दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम में सेव किया गया हो.
  • [C-1-5] मल्टीउपयोगकर्ता को चालू करने पर, एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. ऐसा सिर्फ़ तब किया जाता है, जब डिवाइस पर बाहरी स्टोरेज के एपीआई के लिए, हटाए जा सकने वाले मीडिया का इस्तेमाल किया जाता है. ऐसा सिर्फ़ सिस्टम पर ऐक्सेस न किए जा सकने वाले मीडिया पर सेव कुंजी का इस्तेमाल करके किया जाता है. इससे होस्ट पीसी पर मीडिया को नहीं पढ़ा जा सकेगा. इसलिए, होस्ट पीसी पर मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस देने के लिए, डिवाइस लागू करने के लिए MTP या इससे मिलते-जुलते सिस्टम का इस्तेमाल करना होगा.

अगर लागू किए गए डिवाइसों में कई उपयोगकर्ता शामिल हैं और android.hardware.telephony फ़ीचर फ़्लैग का एलान नहीं किया गया है, तो वे:

  • [C-2-1] प्रतिबंधित प्रोफ़ाइल का इस्तेमाल करना ज़रूरी है. यह एक ऐसी सुविधा है जिससे डिवाइस के मालिक, डिवाइस पर दूसरे उपयोगकर्ताओं और उनकी क्षमताओं को मैनेज कर सकते हैं. प्रतिबंधित प्रोफ़ाइल की मदद से, डिवाइस के मालिक तेज़ी से अलग-अलग एनवायरमेंट सेट अप कर सकते हैं, ताकि अन्य उपयोगकर्ता काम कर सकें. ऐसा करने पर, डिवाइस के मालिक उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन में बेहतर पाबंदियों को मैनेज कर सकते हैं.

अगर लागू किए गए डिवाइस में कई उपयोगकर्ता शामिल हैं और android.hardware.telephony सुविधा फ़्लैग का एलान किया गया है, तो वे:

  • [C-3-1] प्रतिबंधित प्रोफ़ाइल का इस्तेमाल नहीं किया जाना चाहिए, लेकिन अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने से चालू /बंद करने के लिए एओएसपी को लागू करने के तरीकों के साथ अलाइन होना चाहिए.

9.6. प्रीमियम एसएमएस से जुड़ी चेतावनी

Android में, प्रीमियम एसएमएस भेजने वाले लोगों को चेतावनी देने की सुविधा शामिल है. प्रीमियम मैसेज (एसएमएस) ऐसे मैसेज होते हैं जो किसी ऐसी सेवा को भेजे जाते हैं जो मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई है. इसके लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस लागू करने की प्रक्रिया में, android.hardware.telephony के साथ काम करने का एलान किया जाता है, तो ये:

  • [C-1-1] डिवाइस में /data/misc/sms/codes.xml फ़ाइल में तय किए गए रेगुलर एक्सप्रेशन से पहचाने गए नंबर पर मैसेज (एसएमएस) भेजने से पहले उपयोगकर्ताओं को चेतावनी देनी होगी. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट ऐसी सुविधा उपलब्ध कराता है जो इस ज़रूरी शर्त को पूरा करती है.

9.7. सुरक्षा से जुड़ी सुविधाएं

डिवाइस लागू करने के लिए यह पक्का करना ज़रूरी है कि कर्नेल और प्लैटफ़ॉर्म, दोनों में सुरक्षा सुविधाओं का पालन किया गया हो, जैसा कि नीचे बताया गया है.

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो Linux कर्नेल के लिए, सुरक्षा के बेहतर बनाए गए Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करना जारी रखना ज़रूरी है, भले ही SELinux या कोई अन्य सुरक्षा सुविधा Android फ़्रेमवर्क के नीचे लागू की गई हो.
  • [C-0-2] Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा की मदद से, सुरक्षा से जुड़े किसी उल्लंघन का पता चलने और उसे ब्लॉक करने पर, यूज़र इंटरफ़ेस नहीं दिखना चाहिए. हालांकि, सुरक्षा से जुड़ी किसी नीति का उल्लंघन होने पर, इसका यूज़र इंटरफ़ेस दिख सकता है.
  • [C-0-3] SELinux या Android फ़्रेमवर्क के नीचे लागू की गई किसी भी दूसरी सुरक्षा सुविधा को उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर नहीं करना चाहिए.
  • [C-0-4] ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो काम करने के तरीके में गड़बड़ी करने वाली नीति को कॉन्फ़िगर करने के लिए, एपीआई (जैसे कि Device Administration API) के ज़रिए दूसरे ऐप्लिकेशन पर असर डाल सकता है.
  • [C-0-5] मीडिया फ़्रेमवर्क को एक से ज़्यादा प्रोसेस में बांटना ज़रूरी है, ताकि Android ओपन सोर्स प्रोजेक्ट की साइट में दी गई जानकारी के हिसाब से, हर प्रोसेस को बारीकी से ऐक्सेस दिया जा सके.
  • [C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग तकनीक लागू करनी ज़रूरी है. इससे मल्टीथ्रेड प्रोग्राम की कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके, सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट इस ज़रूरत को पूरा करता है. इसके लिए, source.android.com के Kernel कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके के मुताबिक, Threadgroup सिंक करने की सुविधा के साथ seccomp-BPF को चालू किया जाता है.

Kernel इंटिग्रिटी और खुद की सुरक्षा से जुड़ी सुविधाएं, Android की सुरक्षा का ज़रूरी हिस्सा हैं. डिवाइस पर यह सुविधा लागू करना:

  • [C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो सुरक्षा को लागू करना ज़रूरी है (जैसे, CONFIG_CC_STACKPROTECTOR_STRONG).
  • [C-0-8] कर्नेल मेमोरी सुरक्षा के लिए सख्त नियम लागू करना ज़रूरी है.इनमें एक्ज़ीक्यूटेबल कोड रीड-ओनली होता है, रीड-ओनली डेटा होता है और उसे एक्ज़ीक्यूट नहीं किया जा सकता. साथ ही, लिखा गया डेटा एक्ज़ीक्यूट नहीं किया जा सकता (जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX).
  • [C-0-9] एपीआई लेवल 28 या उससे बाद के वर्शन की शिपिंग वाले डिवाइसों पर, यूज़र-स्पेस और कर्नेल-स्पेस (जैसे, CONFIG_HARDENED_USERCOPY) के बीच कॉपी की जांच करने के लिए, स्टैटिक और डाइनैमिक ऑब्जेक्ट साइज़ की सीमा लागू करनी होगी.
  • [C-0-10] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, कर्नेल मोड (जैसे कि हार्डवेयर PXN के ज़रिए या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN की मदद से एम्युलेट किए गए) में, यूज़र-स्पेस मेमोरी एक्ज़ीक्यूट नहीं करनी चाहिए.
  • [C-0-11] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, कर्नेल में यूज़र कॉपी ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN की मदद से एम्युलेट किए गए) के बाहर, यूज़र-स्पेस मेमोरी को पढ़ना या लिखना नहीं चाहिए.
  • [C-0-12] उन सभी डिवाइसों पर कर्नेल पेज टेबल आइसोलेशन लागू करना ज़रूरी है जो मूल रूप से एपीआई लेवल 28 या उसके बाद के लेवल (जैसे कि CONFIG_PAGE_TABLE_ISOLATION या `CONFIG_UNMAP_KERNEL_AT_EL0) के साथ शिपिंग किए जाते हैं.
  • [SR] कर्नेल डेटा को बनाए रखने के लिए इसका बहुत ज़्यादा सुझाव दिया जाता है, जो कि शुरू करने के बाद सिर्फ़ रीड-ओनली के तौर पर मार्क किया गया है (जैसे, __ro_after_init).
  • [SR] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने और ऐसे एक्सपोज़र से बचने के लिए बहुत ज़्यादा सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन की समस्या पैदा हो. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE).

अगर डिवाइस लागू करने के लिए Linux कर्नेल का इस्तेमाल किया जाता है, तो वे:

  • [C-1-1] SELinux को लागू करना ज़रूरी है.
  • [C-1-2] SELinux को ग्लोबल लागू मोड पर सेट करना ज़रूरी है.
  • [C-1-3] सभी डोमेन को लागू करने वाले मोड में कॉन्फ़िगर करना ज़रूरी है. डिवाइस/वेंडर के लिए खास डोमेन समेत, अनुमति देने वाले मोड वाले किसी भी डोमेन की अनुमति नहीं है.
  • [C-1-4] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (AOSP) में दिए गए सिस्टम/सेपॉलिसी फ़ोल्डर में मौजूद नियमों को कभी न बदलने, हटाने या बदलने का काम नहीं करना चाहिए. साथ ही, इस नीति को AOSP SELinux डोमेन के साथ-साथ डिवाइस/वेंडर के खास डोमेन के साथ-साथ सभी मौजूदा नियमों के साथ कंपाइल करना ज़रूरी है.
  • [C-1-5] हर ऐप्लिकेशन की निजी डेटा डायरेक्ट्री पर हर ऐप्लिकेशन के SELinux प्रतिबंध के साथ हर ऐप्लिकेशन SELinux सैंडबॉक्स में एपीआई लेवल 28 या उससे बाद के लेवल को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन चलाना ज़रूरी है.
  • अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट के सिस्टम/sepolicy फ़ोल्डर में दी गई SELinux नीति को बनाए रखना चाहिए और इस नीति में डिवाइस के हिसाब से खास तौर पर बने उनके कॉन्फ़िगरेशन के लिए ही इस नीति को जोड़ना चाहिए.

अगर डिवाइस पर लागू किए गए डिवाइस, Android के पुराने वर्शन पर पहले ही लॉन्च किए जा चुके हैं, लेकिन सिस्टम सॉफ़्टवेयर अपडेट की मदद से ज़रूरी शर्तों [C-1-1] और [C-1-5] को पूरा नहीं किया जा सकता, तो उन्हें इन ज़रूरी शर्तों से छूट दी जा सकती है.

अगर डिवाइस लागू करने के लिए, Linux के अलावा कर्नेल का इस्तेमाल किया जाता है, तो वे:

  • [C-2-1] ज़रूरी ऐक्सेस कंट्रोल सिस्टम का इस्तेमाल करना ज़रूरी है, जो SELinux के जैसा होता है.

Android में सुरक्षा का दायरा बढ़ाने वाली कई सुविधाएं शामिल हैं, जो डिवाइस की सुरक्षा के लिए बहुत ज़रूरी हैं.

डिवाइस पर यह सुविधा लागू करना:

  • [C-SR] इस बात पर ज़ोर दिया जाता है कि उन कॉम्पोनेंट पर कंट्रोल-फ़्लो इंटेग्रिटी (सीएफ़आई) या Integer ओवरफ़्लो सैनिटाइज़ेशन (IntSan) को बंद न करें जिन पर इसे चालू किया गया है.
  • [C-SR] का खास तौर पर सुझाव दिया जाता है कि सीएफ़आई और IntSan, दोनों को सुरक्षा के लिहाज़ से संवेदनशील यूज़रस्पेस कॉम्पोनेंट के लिए चालू किया जा सके. इसके बारे में सीएफ़आई और IntSan में बताया गया है.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद के इतिहास को सेव करता है और UseStatsManager की मदद से इस तरह के इतिहास को मैनेज करता है.

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] इस तरह के उपयोगकर्ता के इतिहास को बनाए रखने की अवधि को उचित रखना चाहिए.
  • [SR] 'निजी डेटा के रखरखाव के लिए 14 दिनों की अवधि' को बनाए रखने का सुझाव दिया जाता है. यह एओएसपी लागू करने के दौरान, डिफ़ॉल्ट रूप से कॉन्फ़िगर किया जाता है.

Android, StatsLog आइडेंटिफ़ायर का इस्तेमाल करके, सिस्टम इवेंट सेव करता है. साथ ही, ऐसे इतिहास को StatsManager और IncidentManager के System API की मदद से मैनेज करता है.

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-2] सिस्टम एपीआई क्लास IncidentManager से बनाई गई, घटना की रिपोर्ट में सिर्फ़ DEST_AUTOMATIC से मार्क किए गए फ़ील्ड शामिल करने होंगे.
  • [C-0-3] StatsLog SDK टूल के दस्तावेज़ों में दी गई जानकारी के अलावा, किसी और इवेंट को लॉग करने के लिए, सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं करना चाहिए. अगर सिस्टम से जुड़े अन्य इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच की रेंज में किसी दूसरे ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्ड किया जा रहा है

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] इस तरह के सॉफ़्टवेयर कॉम्पोनेंट को पहले से लोड नहीं करना चाहिए और न ही ऐसे सॉफ़्टवेयर कॉम्पोनेंट को किसी के साथ शेयर करना चाहिए जो उपयोगकर्ता की निजी जानकारी (जैसे कि कीस्ट्रोक, स्क्रीन पर दिखाया गया टेक्स्ट) को उपयोगकर्ता की सहमति के बिना या चल रही सूचनाओं के बिना भेजते हैं.

अगर डिवाइस पर, सिस्टम में कोई ऐसा फ़ंक्शन शामिल है जो स्क्रीन पर दिखाए गए कॉन्टेंट को कैप्चर करता है और/या डिवाइस पर चल रहे ऑडियो स्ट्रीम को रिकॉर्ड करता है, तो ये काम किए जा सकते हैं:

  • [C-1-1] इस सुविधा के चालू होने और कैप्चर/रिकॉर्ड किए जाने पर, उपयोगकर्ता को इसकी सूचना दी जानी चाहिए.

अगर डिवाइस में कोई ऐसा कॉम्पोनेंट शामिल है जिसे आउट-ऑफ़-बॉक्स चालू किया गया है, तो ऐंबियंट ऑडियो रिकॉर्ड करके उपयोगकर्ता के कॉन्टेक्स्ट के बारे में काम की जानकारी हासिल की जा सकती है. इसके लिए, ये काम किए जा सकते हैं:

  • [C-2-1] उपयोगकर्ता की सहमति के बिना, इसे डिवाइस के लगातार स्टोरेज में सेव नहीं करना चाहिए. इसके अलावा, रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस से बाहर नहीं रखना चाहिए जिसे वापस ओरिजनल ऑडियो या फ़ैक्स में बदला जा सके.

9.8.3. कनेक्टिविटी

अगर डिवाइस पर, यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) की सुविधा वाला यूएसबी पोर्ट है, तो वे:

  • [C-1-1] यूएसबी पोर्ट पर शेयर किए गए स्टोरेज के कॉन्टेंट को ऐक्सेस करने की अनुमति देने से पहले, यूज़र इंटरफ़ेस दिखाना ज़रूरी है. इसमें उपयोगकर्ता की सहमति मांगी जाएगी.

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] सिस्टम के भरोसेमंद सर्टिफ़िकेट देने वाली संस्था (सीए) के स्टोर के लिए, उन्हीं रूट सर्टिफ़िकेट को पहले से इंस्टॉल करना होगा जो अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में दिए गए हैं.
  • [C-0-2] उपयोगकर्ता के रूट वाले सीए स्टोर के साथ शिप करना ज़रूरी है.
  • [C-0-3] उपयोगकर्ता को एक चेतावनी दिखानी होगी, जो यह बताती हो कि उपयोगकर्ता रूट CA जोड़े जाने पर, नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.

अगर डिवाइस ट्रैफ़िक को वीपीएन के ज़रिए रूट किया जाता है, तो डिवाइस लागू करने के लिए:

  • [C-1-1] उपयोगकर्ता को एक चेतावनी दिखानी होगी, जिसमें यह बताया गया हो:
    • उस नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.
    • उस नेटवर्क ट्रैफ़िक को, वीपीएन देने वाले खास वीपीएन ऐप्लिकेशन के ज़रिए रूट किया जा रहा है.

अगर डिवाइस पर लागू करने का कोई ऐसा तरीका है जो डिफ़ॉल्ट रूप से आउट-ऑफ़-बॉक्स चालू होता है, तो नेटवर्क डेटा ट्रैफ़िक को प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए रूट किया जाता है. उदाहरण के लिए, android.permission.CONTROL_VPN की अनुमति वाली वीपीएन सेवा को पहले से लोड करना, तो:

  • [C-2-1] इस तरीके को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. अगर वीपीएन को डिवाइस नीति नियंत्रक ने DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए चालू किया है , तो उपयोगकर्ता को अलग से सहमति देने की ज़रूरत नहीं होगी. हालांकि, आपको इसकी सिर्फ़ सूचना देनी होगी.

अगर डिवाइसों को लागू करने के लिए, किसी तीसरे पक्ष के वीपीएन ऐप्लिकेशन के "हमेशा चालू रहने वाले वीपीएन" फ़ंक्शन को टॉगल करने के लिए, उपयोगकर्ता की सहमति को लागू किया जाता है, तो वे:

  • [C-3-1] SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करके, उन ऐप्लिकेशन के लिए उपयोगकर्ताओं के लिए इस विकल्प को बंद करना ज़रूरी है जो AndroidManifest.xml फ़ाइल में, हमेशा चालू रहने वाली वीपीएन सेवा की सुविधा नहीं देते.

9.9. डेटा स्टोरेज सुरक्षित करने का तरीका

अगर ऐडवांस्ड एन्क्रिप्शन स्टैंडर्ड (AES) क्रिप्टो परफ़ॉर्मेंस, जिसे डिवाइस पर उपलब्ध सबसे अच्छी परफ़ॉर्मेंस देने वाली एईएस टेक्नोलॉजी (जैसे कि ARM क्रिप्टोग्राफ़ी एक्सटेंशन) की मदद से मेज़र किया जाता है, तो यह 50 एमबी/सेकंड से ज़्यादा है, तो डिवाइस को इस तरह लागू करें:

  • [C-1-1] ऐप्लिकेशन के निजी डेटा (/data पार्टिशन) के डेटा स्टोरेज को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.साथ ही, अगर यह डिवाइस का स्थायी हिस्सा है, तो ऐप्लिकेशन के शेयर किए गए स्टोरेज के पार्टीशन (/sdcard पार्टीशन) पर भी काम करना चाहिए. हालांकि, आम तौर पर शेयर किए गए डिवाइस (जैसे, टेलीविज़न) को लागू करने के तरीके को एन्क्रिप्ट नहीं किया जाता.
  • [C-1-2] जब उपयोगकर्ता आउट-ऑफ़-बॉक्स सेटअप अनुभव पूरा कर लेता है, उस समय डेटा स्टोरेज एन्क्रिप्शन को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. हालांकि, आम तौर पर शेयर किए गए डिवाइस (जैसे कि Television) को छोड़कर, डेटा स्टोरेज को एन्क्रिप्ट (सुरक्षित) करने की सुविधा चालू करना ज़रूरी है.

अगर एईएस3 सेक्शन 50 MiB/sec. एईएस3: AES3 सेक्शन 50 MiB/sec. से कम या इससे कम है, तो AES-सेक्शन 'AES1. AES3 [AES-3 सेक्शन, इनमें से किसी में भी Adiantum-XChaCha12-AES के बजाय, इस फ़ॉर्मैट का इस्तेमाल करें: सेक्शन 9.9.2 में AES-256-XTS. [C-1-5] में AES-256 [C-1-5]. AES-256 में सीबीएस-सीटीएस9.

अगर डिवाइसों को Android के पुराने वर्शन पर पहले ही लॉन्च किया जा चुका है और वे सिस्टम सॉफ़्टवेयर अपडेट की मदद से ज़रूरी शर्तों को पूरा नहीं कर पाते हैं, तो उन्हें ऊपर बताई गई ज़रूरी शर्तों से छूट मिल सकती है.

डिवाइस पर यह सुविधा लागू करना:

9.9.1. डायरेक्ट बूट

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] डायरेक्ट बूट मोड एपीआई को लागू करना ज़रूरी है, भले ही वे स्टोरेज एन्क्रिप्ट (सुरक्षित) करने के तरीके के साथ काम न करते हों.

  • [C-0-2] ACTION_LOCKED_BOOT_COMPLETED और ACTION_USER_UNLOCKED इंटेंट को अब भी डायरेक्ट बूट की जानकारी देने वाले ऐप्लिकेशन को यह बताने के लिए ब्रॉडकास्ट किया जाना ज़रूरी है कि डिवाइस को एन्क्रिप्ट (सुरक्षित) किया गया है (DE) और क्रेडेंशियल एन्क्रिप्ट (सुरक्षित) किया गया (सीई) की जगह की जानकारी.

9.9.2. फ़ाइल आधारित एन्क्रिप्शन

अगर डिवाइस लागू करने के तरीके एफ़बीई के साथ काम करते हैं, तो वे:

  • [C-1-1] उपयोगकर्ता को क्रेडेंशियल के लिए चुनौती दिए बिना चालू होना चाहिए और ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डायरेक्ट बूट की जानकारी वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट किए गए (DE) स्टोरेज को ऐक्सेस करने की अनुमति दें.
  • [C-1-2] उपयोगकर्ता को क्रेडेंशियल एन्क्रिप्ट किए गए (सीई) स्टोरेज का ऐक्सेस तब ही देना चाहिए, जब उपयोगकर्ता अपने क्रेडेंशियल (जैसे कि पासवर्ड, पिन, पैटर्न या फ़िंगरप्रिंट) देकर डिवाइस को अनलॉक करे और ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट हो.
  • [C-1-3] उपयोगकर्ता के दिए गए क्रेडेंशियल या रजिस्टर की गई एस्क्रो कुंजी के बिना, CE की मदद से सुरक्षित किए गए स्टोरेज को अनलॉक करने का कोई तरीका ऑफ़र नहीं करना चाहिए.
  • [C-1-4] ज़रूरी है कि ये वेरिफ़ाइड बूट की सुविधा के साथ काम करते हों. साथ ही, यह पक्का करें कि डीई कुंजियां, डिवाइस के हार्डवेयर रूट के साथ क्रिप्टोग्राफ़िक तरीके से जुड़ी हों.
  • [C-1-5] AES-256-XTS का इस्तेमाल करके फ़ाइल के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करने की सुविधा ज़रूरी है. AES-256-XTS का मतलब 256-बिट की कुंजी वाली ऐडवांस्ड एन्क्रिप्शन स्टैंडर्ड से है, जो XTS मोड में काम करती है. XTS कुंजी की पूरी लंबाई 512 बिट होती है.

  • [C-1-6] CBC-CTS मोड में, AES-256 का इस्तेमाल करके फ़ाइल के नाम को एन्क्रिप्ट (सुरक्षित) करने की सुविधा काम करनी चाहिए.

  • CE और DE स्टोरेज एरिया की सुरक्षा करने वाली कुंजियां:

  • [C-1-7] हार्डवेयर-बैक्ड कीस्टोर से क्रिप्टोग्राफ़िक तौर पर जुड़ा होना ज़रूरी है.

  • [C-1-8] सीई कुंजियां इस्तेमाल करने वाले व्यक्ति के लॉक स्क्रीन क्रेडेंशियल से जुड़ी होनी चाहिए.
  • [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासवर्ड से जोड़ना होगा.

  • [C-1-10] यूनीक और अलग होना चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की CE या DE कुंजी किसी दूसरे उपयोगकर्ता की CE या DE कुंजियों से मेल नहीं खाती.

  • [C-1-11] डिफ़ॉल्ट रूप से, बुनियादी तौर पर काम करने वाले साइफ़र, बटन की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है.

  • [C-SR] का खास तौर पर सुझाव दिया जाता है कि फ़ाइल सिस्टम के मेटाडेटा, जैसे कि फ़ाइल का साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs) को एन्क्रिप्ट (सुरक्षित) किया जाए. इसके लिए, क्रिप्टोग्राफ़िक तरीके से डिवाइस के हार्डवेयर रूट को सुरक्षित रखा जाता है.

  • पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, मैसेंजर) के डायरेक्ट बूट की जानकारी होनी चाहिए.

  • फ़ाइल का कॉन्टेंट और फ़ाइल के नाम को एन्क्रिप्ट (सुरक्षित) करने के लिए, वैकल्पिक साइफ़र, कुंजी की लंबाई, और मोड का इस्तेमाल किया जा सकता है.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नेल ext4 एन्क्रिप्शन सुविधा के आधार पर, इस सुविधा को पसंदीदा तरीके से लागू करने की सुविधा देता है.

9.9.3. डिस्क को पूरी तरह सुरक्षित (सुरक्षित) करने का तरीका

अगर डिवाइस पर डिस्क के पूरे एन्क्रिप्शन (एफ़डीई) की सुविधा काम करती है, तो ये कार्रवाइयां की जाती हैं:

  • [C-1-1] AES का इस्तेमाल ऐसे मोड में करना चाहिए जिसे स्टोरेज के लिए डिज़ाइन किया गया हो (जैसे, XTS या CBC-ESSIV). साथ ही, साइफ़र कुंजी की लंबाई 128 बिट या इससे ज़्यादा होनी चाहिए.
  • [C-1-2] एन्क्रिप्शन कुंजी को रैप करने के लिए, डिफ़ॉल्ट पासवर्ड का इस्तेमाल करना ज़रूरी है. साथ ही, एन्क्रिप्ट (सुरक्षित) किए बिना, किसी भी समय डिवाइस के स्टोरेज में एन्क्रिप्ट (सुरक्षित) करने का पासकोड नहीं लिखना चाहिए.
  • [C-1-3] जब तक उपयोगकर्ता साफ़ तौर पर ऑप्ट आउट नहीं करता, तब तक एन्क्रिप्शन कुंजी को डिफ़ॉल्ट रूप से एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. ऐसा तब नहीं होगा, जब लॉक स्क्रीन के क्रेडेंशियल, धीमे स्ट्रेचिंग वाले एल्गोरिदम (जैसे, PBKDF2 या Scrypt) का इस्तेमाल करके बढ़ाए गए हों.
  • [C-1-4] जब उपयोगकर्ता ने लॉक स्क्रीन क्रेडेंशियल न बताया हो या डिवाइस पर पासवर्ड एन्क्रिप्ट (सुरक्षित) करने के लिए पासवर्ड का इस्तेमाल बंद कर दिया हो और डिवाइस हार्डवेयर-बैक्ड कीस्टोर उपलब्ध कराता हो, तब ऊपर दिए गए डिफ़ॉल्ट पासवर्ड स्ट्रेचिंग एल्गोरिदम को क्रिप्टोग्राफ़िक तरीके से उस कीस्टोर से जोड़ा जाना चाहिए.
  • [C-1-5] डिवाइस पर एन्क्रिप्ट (सुरक्षित) करने की कुंजी नहीं भेजनी चाहिए (भले ही, इसे उपयोगकर्ता के पासवर्ड और/या हार्डवेयर की सुरक्षा कुंजी के साथ रैप किया गया हो).

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नेल सुविधा dm-crypt के आधार पर इस सुविधा को प्राथमिकता के साथ लागू करने की सुविधा देता है.

9.10. डिवाइस इंटिग्रिटी

इन ज़रूरी शर्तों को पूरा करने पर, डिवाइस को पूरी सुरक्षा देने की सुविधा की स्थिति के बारे में साफ़ तौर पर जानकारी दी जाती है. डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] सिस्टम एपीआई वाले तरीके PersistentDataBlockManager.getFlashLockState() का इस्तेमाल करके, सही तरीके से इसकी रिपोर्ट करना ज़रूरी है कि उनके बूटलोडर की स्थिति, सिस्टम की इमेज फ़्लैश करने की अनुमति देती है या नहीं. FLASH_LOCK_UNKNOWN स्थिति, Android के किसी पुराने वर्शन से अपग्रेड किए जाने वाले डिवाइस के लिए रिज़र्व है. इसमें सिस्टम एपीआई का यह नया तरीका मौजूद नहीं था.

  • [C-0-2] डिवाइस इंटिग्रिटी के लिए, वेरिफ़ाइड बूट की सुविधा दी जानी चाहिए.

अगर Android के पुराने वर्शन पर, वेरिफ़ाइड बूट की सुविधा दिए बिना ही डिवाइस लागू करने की सुविधा लॉन्च की जाती है और सिस्टम सॉफ़्टवेयर अपडेट के साथ इस सुविधा के लिए सहायता नहीं जोड़ी जा सकती, तो उन्हें इस ज़रूरी शर्त से छूट दी जा सकती है.

वेरिफ़ाइड बूट की सुविधा, डिवाइस के सॉफ़्टवेयर को सुरक्षित रखने की गारंटी देती है. अगर लागू किए गए डिवाइस पर यह सुविधा काम करती है, तो वे:

  • [C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग android.software.verified_boot के बारे में बताना ज़रूरी है.
  • [C-1-2] ज़रूरी है कि हर बूट क्रम पर पुष्टि करनी हो.
  • [C-1-3] ज़रूरी है कि नहीं बदले जा सकने वाले हार्डवेयर कुंजी से, पुष्टि की प्रोसेस शुरू की जाए. यह कुंजी, भरोसे की मूल वजह है और इसे सिस्टम पार्टिशन के लिए इस्तेमाल किया गया है.
  • [C-1-4] कोड को अगले चरण में लागू करने से पहले, अगले चरण में सभी बाइट के भरोसेमंद और सही होने की जांच करने के लिए, पुष्टि करने के हर चरण को लागू करना ज़रूरी है.
  • [C-1-5] हैशिंग एल्गोरिदम (SHA-256) और सार्वजनिक पासकोड साइज़ (RSA-2048) के लिए, पुष्टि करने वाले एल्गोरिदम का इस्तेमाल, एनआईएसटी से मिले मौजूदा सुझावों जितना ही होना चाहिए.
  • [C-1-6] सिस्टम की पुष्टि न हो पाने पर, डिवाइस को बूट करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक उपयोगकर्ता डिवाइस को फिर से चालू करने की सहमति न दे. ऐसा होने पर, ऐसे स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाएगा जिसकी पुष्टि नहीं हुई है.
  • [C-1-7] डिवाइस के ऐसे हिस्सों में बदलाव करने की अनुमति नहीं देनी चाहिए जिनकी पुष्टि हो चुकी है. ऐसा तब तक नहीं होना चाहिए, जब तक उपयोगकर्ता ने साफ़ तौर पर बूटलोडर को अनलॉक न कर दिया हो.
  • [C-SR] अगर डिवाइस में कई अलग-अलग चिप हैं (जैसे कि रेडियो, खास इमेज प्रोसेसर), तो बूट करने के हर चरण की पुष्टि करने के लिए उनमें से हर चिप को चालू करने का सुझाव दिया जाता है.
  • [C-1-8] छेड़छाड़ करके साफ़ तौर पर दिखने वाले स्टोरेज का इस्तेमाल करना ज़रूरी है: इससे यह स्टोर किया जा सकेगा कि बूटलोडर अनलॉक है या नहीं. छेड़छाड़ होने पर पता चलने वाली मेमोरी का मतलब है कि बूट लोडर यह पता लगा सकता है कि Android में स्टोरेज के साथ छेड़छाड़ की गई है या नहीं.
  • [C-1-9] डिवाइस इस्तेमाल करते समय, उपयोगकर्ता को निर्देश देना होगा. साथ ही, बूट लोडर को लॉक किए गए मोड से बूट लोडर अनलॉक मोड में स्विच करने से पहले, व्यक्ति से उसकी पुष्टि कराना ज़रूरी है.
  • [C-1-10] Android की ओर से इस्तेमाल किए जाने वाले हिस्सों (जैसे कि बूट, सिस्टम पार्टिशन) के लिए रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, ओएस के सबसे कम वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, ऐसे स्टोरेज का इस्तेमाल करें जिससे छेड़छाड़ होती है.
  • [C-SR] काफ़ी हद तक इस बात का सुझाव दिया जाता है कि खास अधिकार रखने वाली ऐप्लिकेशन APK फ़ाइलों की पुष्टि, /system में रूट की गई ट्रस्ट चेन के साथ की जाए. इसे वेरिफ़ाइड बूट की मदद से सुरक्षित किया जाता है.
  • [सी-एसआर] का सुझाव इस तरह दिया जाता है कि किसी खास ऐप्लिकेशन के ज़रिए लोड किए गए ऐसे आर्टफ़ैक्ट की पुष्टि की जाए जिसे उसकी APK फ़ाइल के बाहर से लोड किया गया हो. जैसे, डाइनैमिक तरीके से लोड किया गया कोड या कंपाइल किया गया कोड. इसके अलावा, इस बात की बहुत ज़्यादा सलाह दी जाती है कि उन आर्टफ़ैक्ट को एक्ज़ीक्यूट न किया जाए.
  • स्थायी फ़र्मवेयर (जैसे मॉडम, कैमरा) वाले किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू करनी चाहिए. साथ ही, सबसे कम अनुमति वाले वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, ऐसे स्टोरेज का इस्तेमाल करना चाहिए जिससे छेड़छाड़ न की जा सके.

अगर Android के पुराने वर्शन पर, डिवाइसों को C-1-8 से लेकर C-1-10 तक के काम किए बिना पहले ही लॉन्च कर दिया गया है और सिस्टम सॉफ़्टवेयर अपडेट के साथ इन ज़रूरतों के लिए सहायता नहीं जोड़ी जा सकती है, तो उन्हें ज़रूरी शर्तों से छूट दी जा सकती है.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ डेटा स्टोर करने की जगह में इस सुविधा को लागू करने का पसंदीदा तरीका उपलब्ध कराता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूट लोडर में इंटिग्रेट किया जा सकता है.

डिवाइस पर यह सुविधा लागू करना:

  • [C-R] हमारा सुझाव है कि Android Protected Safety API के साथ काम किया जा सके.

अगर डिवाइस इंप्लिमेंटेशन Android ProtectedConfirm API की सुविधा के साथ काम करता है, तो वे:

  • [C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true को रिपोर्ट करना ज़रूरी है.
  • [C-3-2] आपको यह पक्का करना होगा कि सुरक्षित हार्डवेयर, डिसप्ले को इस तरह से कंट्रोल करता है कि सुरक्षित हार्डवेयर उसे पहचाने बिना Android OS उसे ब्लॉक न कर सके.
  • [C-3-3] यह पक्का करना ज़रूरी है कि सुरक्षित हार्डवेयर को टचस्क्रीन का पूरा कंट्रोल मिले.

9.11. कुंजियां और क्रेडेंशियल

Android कीस्टोर सिस्टम, ऐप्लिकेशन डेवलपर को किसी कंटेनर में क्रिप्टोग्राफ़िक कुंजियों को सेव करने की अनुमति देता है. साथ ही, वे KeyChain API या Keystore API के ज़रिए, क्रिप्टोग्राफ़िक ऑपरेशन में उनका इस्तेमाल कर सकते हैं. डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति देनी होगी.
  • [C-0-2] लॉक स्क्रीन से पुष्टि करने की प्रक्रिया के लिए, रेट-सीमा तय करना और एक्सपोनेन्शियल बैकऑफ़ एल्गोरिदम होना ज़रूरी है. हर कोशिश में कम से कम 24 घंटे की देरी होनी चाहिए. 150 बार गलत पिन डालने के बाद भी ऐसा नहीं किया जा सकता.
  • जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं किया जाना चाहिए

जब डिवाइस पर लागू होने वाला सुरक्षित लॉक स्क्रीन काम करती है, तो यह काम करता है:

  • [C-1-1] कीस्टोर को लागू करने के तरीके का बैक अप, एक अलग एक्ज़ीक्यूशन एनवायरमेंट के साथ लेना ज़रूरी है.
  • [C-1-2] आरएसए, एईएस, ईसीडीएसए और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू करने ज़रूरी हैं, ताकि Android कीस्टोर सिस्टम के काम करने वाले एल्गोरिदम के सही तरीके से काम किया जा सके. ऐसा क्षेत्र में, कर्नेल और ऊपर वाले कोड पर चल रहे कोड से सुरक्षित तरीके से किया जाना चाहिए. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी), Trusty लागू करने की सुविधा का इस्तेमाल करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या किसी तीसरे पक्ष के समीक्षा किए गए सुरक्षित तरीके से, हायपरवाइज़र-आधारित आइसोलेशन के विकल्प को सुरक्षित तरीके से लागू किया जा सकता है.
  • [C-1-3] लॉक स्क्रीन की पुष्टि अलग-अलग डिवाइसों पर करना ज़रूरी है. साथ ही, पुष्टि करने की प्रक्रिया पूरी होने पर ही, पुष्टि करने वाली कुंजियों के इस्तेमाल की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि लॉक स्क्रीन की पुष्टि करने के लिए, सिर्फ़ एक सुरक्षित एनवायरमेंट को अनुमति मिले. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और Trusty देता है, जिनका इस्तेमाल इस ज़रूरत को पूरा करने के लिए किया जा सकता है.
  • [C-1-4] कुंजी को प्रमाणित करने की प्रक्रिया का इस्तेमाल करना ज़रूरी है, जहां पुष्टि करने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और सुरक्षित हार्डवेयर में हस्ताक्षर किया जाता हो. पुष्टि करने के लिए इस्तेमाल होने वाले साइनिंग पासकोड को, ज़्यादा डिवाइसों के साथ शेयर करना ज़रूरी है, ताकि इनका इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि पुष्टि करने वाली एक ही कुंजी का इस्तेमाल तब तक किया जाए, जब तक किसी SKU की कम से कम 1,00,000 यूनिट न बनाई गई हों. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
  • [C-1-5] लोगों को यह तय करने की अनुमति देनी होगी कि स्लीप टाइम आउट की सुविधा चालू होने पर, किसी लॉक की स्थिति में स्विच किया जा सकता है या नहीं. इस तरह, टाइम आउट की अवधि कम से कम 15 सेकंड होनी चाहिए.

ध्यान दें कि अगर किसी डिवाइस को Android के पुराने वर्शन पर पहले ही लॉन्च किया जा चुका है, तो ऐसे डिवाइस को कीस्टोर के लिए एक अलग एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करने की ज़रूरत नहीं होती. साथ ही, जब तक यह android.hardware.fingerprint सुविधा के बारे में जानकारी नहीं देता, तब तक के लिए ऐसी कीस्टोर की ज़रूरत नहीं होती जिसके लिए एक आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल किया जाता हो.

9.11.1. लॉक स्क्रीन को लॉक करें

एओएसपी को पुष्टि करने के अलग-अलग स्तर वाले मॉडल का इस्तेमाल किया जाता है. इसमें नॉलेज-फ़ैक्ट्री के आधार पर, प्राइमरी ऑथेंटिकेशन का दूसरा मज़बूत बायोमेट्रिक इस्तेमाल किया जा सकता है या तीसरे पक्ष के कमज़ोर तरीकों का इस्तेमाल किया जा सकता है.

डिवाइस पर यह सुविधा लागू करना:

  • [सी-एसआर] का सुझाव दिया जाता है कि पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से किसी एक को ही सेट करें:
    • अंकों वाला पिन
    • अक्षरों और अंकों से बना पासवर्ड
    • 3x3 बिंदुओं के ग्रिड पर स्वाइप पैटर्न

ध्यान दें कि ऊपर दिए गए पुष्टि करने के तरीकों को, इस दस्तावेज़ में पुष्टि करने के मुख्य तरीकों के तौर पर दिखाया गया है.

अगर डिवाइस लागू करने की सुविधा में, पुष्टि करने के मुख्य तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और स्क्रीन लॉक करने के सुरक्षित तरीके के तौर पर, पुष्टि करने का नया तरीका इस्तेमाल किया जाता है, तो पुष्टि करने का नया तरीका:

  • [C-2-1] उपयोगकर्ता की पुष्टि करने का तरीका होना ज़रूरी है, जैसा कि मुख्य इस्तेमाल के लिए उपयोगकर्ता की पुष्टि करना सेक्शन में बताया गया है.
  • [C-2-2] तीसरे पक्ष के डेवलपर ऐप्लिकेशन के लिए सभी कुंजियों को अनलॉक करना ज़रूरी है. ऐसा करना तब ज़रूरी है, जब उपयोगकर्ता सुरक्षित लॉक स्क्रीन को अनलॉक करे. उदाहरण के लिए, तीसरे पक्ष के डेवलपर ऐप्लिकेशन के लिए सभी पासकोड, createConfirmDeviceCredentialIntent और setUserAuthenticationRequired जैसे काम के एपीआई के ज़रिए उपलब्ध होने चाहिए.

अगर डिवाइस, लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ते हैं या उनमें बदलाव करते हैं. ऐसा पहले से पता होता है कि सुरक्षा के नियम के हिसाब से डिवाइस लॉक हो जाता है. ऐसे मामलों में, स्क्रीन लॉक करने के लिए, पुष्टि करने का नया तरीका इस्तेमाल किया जाता है. ऐसा सुरक्षित तरीके से होता है:

  • [C-3-1] इनपुट की सबसे छोटी लंबाई की एंट्रॉपी 10 बिट से ज़्यादा होनी चाहिए.
  • [C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एंट्रॉपी 18 बिट से ज़्यादा होनी चाहिए.
  • [C-3-3] पुष्टि करने के नए तरीके को एओएसपी में लागू और उपलब्ध कराए गए, पुष्टि करने के किसी भी मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) की जगह इस्तेमाल नहीं करना चाहिए.
  • [C-3-4] जब डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके का इस्तेमाल करके, पासवर्ड की क्वालिटी से जुड़ी नीति को PASSWORD_QUALITY_SOMETHING से ज़्यादा सीमित क्वालिटी वाली और सेट की हो, तब पुष्टि करने का नया तरीका बंद करना ज़रूरी है.

अगर डिवाइस पर लागू होने वाला डिवाइस, लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के सुझाए गए मुख्य तरीकों को जोड़ता है या उनमें बदलाव करता है. साथ ही, अगर बायोमेट्रिक्स पर आधारित पुष्टि करने के नए तरीके को स्क्रीन लॉक करने का सुरक्षित तरीका माना जाता है, तो यह नया तरीका:

  • [C-4-1] सेक्शन 7.3.10.2 में बताई गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
  • [C-4-2] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका (फ़ॉल-बैक तरीका) होना चाहिए. यह तरीका, जानी-पहचानी किसी सीक्रेट जानकारी पर आधारित होना चाहिए.
  • [C-4-3] आपको बंद करना होगा और स्क्रीन को अनलॉक करने के लिए, सिर्फ़ सुझाए गए मुख्य तरीके को अनुमति देनी होगी. ऐसा तब ही होगा, जब डिवाइस नीति नियंत्रक (DPC) ऐप्लिकेशन ने किसी भी संबंधित बायोमेट्रिक फ़्लैग (जैसे कि KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल करके, DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके कीगार्ड सुविधा की नीति सेट कर दी हो.
  • [C-4-4] हर 72 घंटे में कम से कम एक बार, उपयोगकर्ता को पहचान की पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) के लिए चुनौती देनी होगी.
  • [C-4-5] गलत स्वीकार करने की दर, फ़िंगरप्रिंट सेंसर के लिए ज़रूरी सेक्शन 7.3.10 के मुताबिक या उससे ज़्यादा होनी चाहिए. ऐसा न होने पर भी इसे बंद करना ज़रूरी है. साथ ही, डिवाइस नीति नियंत्रक (DPC) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके के ज़रिए PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा प्रतिबंधित क्वालिटी कॉन्सटेंट के ज़रिए पासवर्ड क्वालिटी नीति को सेट करने पर ही, मुख्य पुष्टि के लिए सुझाव को बंद करने की अनुमति दी है.
  • [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है कि स्पूफ़ और इंपोस्टर स्वीकार करने की दर, सेक्शन 7.3.10 में दी गई जानकारी के मुताबिक फ़िंगरप्रिंट सेंसर के लिए ज़रूरी या उससे ज़्यादा हो.
  • [C-4-6] के पास एक सुरक्षित प्रोसेसिंग पाइपलाइन होनी चाहिए जैसे कि ऑपरेटिंग सिस्टम या कर्नेल छेड़छाड़ से उपयोगकर्ता के रूप में गलत तरीके से पुष्टि करने के लिए डेटा को सीधे इंजेक्ट नहीं किया जा सकता है.
  • [C-4-7] अगर ऐप्लिकेशन, true को KeyGenParameterSpec.Built.setUserAuthenticationRequired() के लिए सेट करता है और बायोमेट्रिक की मदद से (जैसे, चेहरा या आइरिस, जहां इंटेंट का साफ़ तौर पर कोई सिग्नल मौजूद नहीं है) हो, तो कीस्टोर कुंजियों के ऐक्सेस की अनुमति देने के लिए, साफ़ तौर पर पुष्टि करने वाली कार्रवाई (जैसे, बटन दबाना) के साथ जोड़ा जाना चाहिए.
  • [C-SR] पैसिव बायोमेट्रिक्स के लिए, पुष्टि करने की कार्रवाई को इस तरह सुरक्षित करने का बहुत ज़्यादा सुझाव दिया जाता है कि कोई ऑपरेटिंग सिस्टम या कर्नेल से छेड़छाड़ न की जा सके. उदाहरण के लिए, इसका मतलब है कि फ़िज़िकल बटन पर आधारित 'पुष्टि करने की कार्रवाई' को सुरक्षित एलिमेंट (एसई) के इनपुट-ओनली इनपुट/आउटपुट (GPIO) पिन से रूट किया जाता है. यह पिन, बटन दबाने के बजाय किसी और तरीके से नहीं चलाया जा सकता.

अगर बायोमेट्रिक तरीके से पुष्टि करने के तरीके, सेक्शन 7.3.10 में बताए गए, झूठे नाम से मेल भेजने और उसे स्वीकार करने की दर के हिसाब से नहीं हैं, तो:

  • [C-5-1] अगर डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके का इस्तेमाल करके, पासवर्ड की क्वालिटी से जुड़ी नीति को PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा सीमित क्वालिटी वाली और एक जैसी क्वालिटी में सेट किया है, तो इन तरीकों को बंद करना ज़रूरी है.
  • [C-5-2] चार घंटे तक काम न करने पर टाइम आउट होने के बाद, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे: पिन, पैटर्न, पासवर्ड) के लिए चुनौती देनी होगी. डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, इस्तेमाल में न होने की टाइम आउट अवधि को रीसेट कर दिया जाता है.
  • [C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए. साथ ही, इन्हें नीचे दिए गए सेक्शन में C-8 से शुरू होने वाली शर्तों को पूरा करना होगा.

अगर डिवाइस लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीकों को जोड़ते हैं या उनमें बदलाव करते हैं और पुष्टि करने का नया तरीका किसी फ़िज़िकल टोकन या जगह के हिसाब से होता है, तो:

  • [C-6-1] उनके पास पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका (फ़ॉल-बैक तरीका) होना चाहिए. यह तरीका, जानी-पहचानी सीक्रेट जानकारी पर आधारित होता है और सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल होने से जुड़ी ज़रूरी शर्तों को पूरा करता है.
  • [C-6-2] आपको नया तरीका इस्तेमाल करना होगा और पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक को ही स्क्रीन अनलॉक करने की अनुमति देनी होगी. ऐसा तब होगा, जब डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) तरीके से या DevicePolicyManager.setPasswordQuality() तरीके से नीति को PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा सीमित क्वालिटी वाली पर सेट किया हो.
  • [C-6-3] उपयोगकर्ता को हर 72 घंटे में कम से कम एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक को अपनाना होगा.
  • [C-6-4] इस नए तरीके को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए. साथ ही, इसे नीचे C-8 में बताई गई शर्तों का पालन करना होगा.

अगर लागू किए जाने वाले डिवाइस में एक सुरक्षित लॉक स्क्रीन है और उसमें एक या एक से ज़्यादा ऐसे भरोसेमंद एजेंट शामिल हैं जो TrustAgentService System API को लागू करते हैं, तो वे:

  • [C-7-1] डिवाइस के लॉक में देरी होने या उसे भरोसेमंद एजेंट की मदद से अनलॉक किए जाने पर, सेटिंग मेन्यू और लॉक स्क्रीन पर साफ़ तौर पर इसकी सूचना दी जानी चाहिए. उदाहरण के लिए, एओएसपी इस ज़रूरी शर्त को पूरा करने के लिए, सेटिंग मेन्यू में "अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक हो जाता है" के बारे में टेक्स्ट की जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर एक अलग आइकॉन भी दिखाता है.
  • [C-7-2] DevicePolicyManager क्लास में सभी ट्रस्ट एजेंट एपीआई का पालन करना चाहिए और उन्हें पूरी तरह से लागू करना चाहिए. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्सटेंट.
  • [C-7-3] ऐसे डिवाइस पर TrustAgentService.addEscrowToken() फ़ंक्शन को पूरी तरह लागू नहीं करना चाहिए जिसे मुख्य निजी डिवाइस (जैसे कि हैंडहेल्ड) के तौर पर इस्तेमाल किया जाता हो. हालांकि, इसे आम तौर पर शेयर किए जाने वाले डिवाइस (जैसे कि Android टेलीविज़न या Automotive डिवाइस) पर लागू करने की सुविधा को पूरी तरह लागू किया जा सकता है.
  • [C-7-4] TrustAgentService.addEscrowToken() के जोड़े गए सभी स्टोर किए गए टोकन को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.
  • [C-7-5] एन्क्रिप्शन कुंजी को उस डिवाइस पर सेव नहीं किया जाना चाहिए जिस पर कुंजी का इस्तेमाल किया गया है. उदाहरण के लिए, फ़ोन पर सेव की गई कुंजी के ज़रिए, टीवी पर उपयोगकर्ता खाते को अनलॉक किया जा सकता है.
  • [C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में बताना ज़रूरी है.
  • [C-7-7] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका होना ज़रूरी है.
  • [C-7-8] उपयोगकर्ता को हर 72 घंटे में कम से कम एक बार, पुष्टि करने के सुझाए गए किसी मुख्य तरीके (जैसे: पिन, पैटर्न, पासवर्ड) के लिए चुनौती देनी होगी.
  • [C-7-9] चार घंटे तक काम न करने पर टाइम आउट होने के बाद, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक को लागू करने के लिए चुनौती देनी होगी. जैसे: पिन, पैटर्न, पासवर्ड. डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, इस्तेमाल में न होने की टाइम आउट अवधि को रीसेट कर दिया जाता है.
  • [C-7-10] को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए और नीचे C-8 में बताई गई शर्तों का पालन करना चाहिए.

अगर डिवाइस लागू करने की सुविधा, ऊपर बताए गए तरीके से लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ती है या उनमें बदलाव करती है, तो कीगार्ड अनलॉक करने के लिए पुष्टि करने के नए तरीके का इस्तेमाल करें:

  • [C-8-1] जब डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके का इस्तेमाल करके, पासवर्ड क्वालिटी की नीति को PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा सीमित क्वालिटी वाली और सेट की हो, तब इस नए तरीके को बंद करना ज़रूरी है.
  • [C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() के सेट किए गए पासवर्ड के खत्म होने के टाइमर को रीसेट नहीं करना होगा.
  • [C-8-3] जब ऐप्लिकेशन KeyGenParameterSpec.Builder.setUserAuthenticationRequired() के लिए true सेट करता है, तो उन्हें कीस्टोर के ऐक्सेस की पुष्टि नहीं करनी होगी.

9.11.2. स्ट्रॉन्गबॉक्स

Android कीस्टोर सिस्टम, ऐप्लिकेशन डेवलपर को क्रिप्टोग्राफ़िक कुंजियों को किसी सुरक्षित प्रोसेसर में सेव करने देता है. साथ ही, वे इसे इस्तेमाल किए जाने के लिए, ऊपर बताए गए अलग-अलग एनवायरमेंट में भी सेव कर सकते हैं.

डिवाइस पर यह सुविधा लागू करना:

  • StrongBox के साथ काम करने के लिए [C-SR] का खास तौर पर सुझाव दिया जाता है.

अगर डिवाइस लागू करने की सुविधा StrongBox के साथ काम करती है, तो वे:

  • [C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.

  • [C-1-2] खास तौर पर सुरक्षित हार्डवेयर उपलब्ध कराना ज़रूरी है, जिसका इस्तेमाल कीस्टोर के बैकस्टोर और उपयोगकर्ता की पुष्टि करने के लिए किया जाता है.

  • [C-1-3] ज़रूरी है कि आपके पास एक अलग सीपीयू हो, जो ऐप्लिकेशन प्रोसेसर (AP) के साथ कैश, डीरैम, को-प्रोसेसर या दूसरे मुख्य संसाधनों को शेयर नहीं करता हो.

  • [C-1-4] यह पक्का करना ज़रूरी है कि AP के साथ शेयर किया गया कोई भी सहायक डिवाइस, StrongBox की प्रोसेसिंग में किसी भी तरह से बदलाव न कर सके या StrongBox से कोई जानकारी हासिल न कर सके. एपी, StrongBox का ऐक्सेस बंद कर सकता है या ब्लॉक कर सकता है.

  • [C-1-5] ज़रूरी सटीक (+-10%) वाली एक इंटरनल घड़ी होनी चाहिए. इसमें AP की ओर से बदलाव किए जाने का कोई असर नहीं होता.

  • [C-1-6] ज़रूरी है कि एक रैंडम नंबर जनरेटर हो, जो समान रूप से डिस्ट्रिब्यूट किया जाने वाला और ऐसा आउटपुट देता हो जिसका अनुमान न लगाया जा सके.

  • [C-1-7] शरीर को छेड़ने से रोकने की क्षमता का होना ज़रूरी है. इसमें, शरीर के किसी हिस्से में जाने और ग्लिच से बचाव भी शामिल है.

  • [C-1-8] साइड चैनल के लिए रेज़िस्टेंस होना ज़रूरी है. इसमें पावर, टाइमिंग, इलेक्ट्रोमैग्नेटिक रेडिएशन, और थर्मल रेडिएशन वाले साइड चैनलों से जानकारी लीक होने से रोकने की क्षमता भी शामिल है.

  • [C-1-9] डिवाइस का स्टोरेज सुरक्षित होना चाहिए. इससे कॉन्टेंट की गोपनीयता, विश्वसनीयता, और भरोसेमंद जानकारी एक जैसी होनी चाहिए. साथ ही, यह भी पक्का किया जाता है कि उसमें मौजूद कॉन्टेंट न तो सटीक हो, और न ही सटीक हो. StrongBox API की अनुमति के बिना, स्टोरेज में बदलाव नहीं किया जाना चाहिए और न ही इसे पढ़ा जाना चाहिए.

  • इस बात की पुष्टि करने के लिए कि [C-1-3] से [C-1-9] तक का पालन किया गया है या नहीं, डिवाइस पर ये सुविधाएं लागू की जाती हैं:

    • [C-1-10] ऐसा हार्डवेयर शामिल करना ज़रूरी है जो सुरक्षित आईसी प्रोटेक्शन प्रोफ़ाइल BSI-CC-PP-0084-2014 से सर्टिफ़ाइड है या जिसका आकलन राष्ट्रीय स्तर की किसी टेस्टिंग लैबोरेट्री से किया गया है. इसमें जोखिम की संभावना का आकलन करने के लिए, स्मार्टकार्ड पर हमले की संभावना का सामान्य मानदंड के तहत आकलन किया गया है.
    • [C-1-11] फ़र्मवेयर को शामिल करना ज़रूरी है. इसका आकलन, राष्ट्रीय स्तर पर मान्यता पा चुकी टेस्टिंग लैबोरेट्री से किया गया है. इसमें अटैक पोटेंशियल ऐप्लिकेशन ऑफ़ स्मार्टकार्ड्स के मुताबिक, जोखिम की संभावना का ज़्यादा से ज़्यादा आकलन किया गया है.
    • [सी-एसआर] हमारा सुझाव है कि इसमें वह हार्डवेयर शामिल किया जाए जिसका आकलन AVA_VAN.5 की मदद से, सुरक्षा टारगेट, इवैलुएशन अश्योरेंस लेवल (ईएएल) 5 का इस्तेमाल करके किया जाता है. आने वाले समय में, EAL 5 सर्टिफ़िकेशन ज़रूरी हो सकता है.

  • [C-SR] का इनसाइडर अटैक रेज़िस्टेंस (IAR) देने के लिए बहुत ज़्यादा सुझाव दिया जाता है. इसका मतलब है कि फ़र्मवेयर साइनिंग कुंजियों का ऐक्सेस रखने वाला इनसाइडर ऐसा फ़र्मवेयर नहीं बना सकता जिसकी वजह से StrongBox, सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास कर सके या उपयोगकर्ता के संवेदनशील डेटा का ऐक्सेस चालू कर सके. IAR लागू करने का सुझाया गया तरीका, फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब देना है, जब IAuthSecret HAL के ज़रिए मुख्य उपयोगकर्ता पासवर्ड दिया गया हो.

9.12. डेटा हटाना

लागू किए गए सभी डिवाइस:

  • [C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका देना ज़रूरी है.
  • [C-0-2] उपयोगकर्ता का जनरेट किया गया सारा डेटा मिटाना ज़रूरी है. इसका मतलब है कि इन चीज़ों को छोड़कर, बाकी सारा डेटा:
    • सिस्टम की इमेज
    • ऑपरेटिंग सिस्टम में मौजूद ऐसी फ़ाइलें जिन्हें सिस्टम इमेज के लिए ज़रूरी है
  • [C-0-3] डेटा को इस तरह से मिटाना चाहिए कि इससे काम के इंडस्ट्री स्टैंडर्ड, जैसे कि NIST SP800-88 पूरे किए जा सकें.
  • [C-0-4] प्राइमरी यूज़र के डिवाइस पॉलिसी कंट्रोलर ऐप्लिकेशन से DevicePolicyManager.wipeData() एपीआई को कॉल करने पर, ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
  • इसमें तेज़ी से डेटा वाइप करने का विकल्प दिया जा सकता है, जो सिर्फ़ लॉजिकल डेटा को हमेशा के लिए मिटाने की सुविधा देता है.

9.13. सुरक्षित बूट मोड

Android, सुरक्षित बूट मोड की सुविधा देता है. इस मोड की मदद से उपयोगकर्ता, डिवाइस को ऐसे मोड में चालू कर सकते हैं जिसमें सिर्फ़ पहले से इंस्टॉल किए गए सिस्टम ऐप्लिकेशन इस्तेमाल किए जा सकते हों और तीसरे पक्ष के सभी ऐप्लिकेशन बंद हों. "सुरक्षित बूट मोड" के नाम से जाना जाने वाला मोड, उपयोगकर्ता को तीसरे पक्ष के संभावित नुकसान पहुंचाने वाले ऐप्लिकेशन अनइंस्टॉल करने की सुविधा देता है.

इन डिवाइस पर ये सुविधाएं लागू की जा सकती हैं:

  • [SR] सुरक्षित बूट मोड लागू करने के लिए खास तौर पर सुझाव दिया जाता है.

अगर डिवाइस लागू करने वाले सुरक्षित बूट मोड लागू करते हैं, तो वे:

  • [C-1-1] लोगों को सुरक्षित बूट मोड इस्तेमाल करने का विकल्प देना ज़रूरी है, ताकि वे डिवाइस पर इंस्टॉल किए गए तीसरे पक्ष के ऐप्लिकेशन इस्तेमाल कर सकें. ऐसा सिर्फ़ तब किया जा सकता है, जब तीसरे पक्ष का ऐप्लिकेशन, डिवाइस नीति नियंत्रक है और उसने UserManager.DISALLOW_SAFE_BOOT फ़्लैग को सही के तौर पर सेट किया हो.

  • [C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा देनी ज़रूरी है.

  • उपयोगकर्ता को बूट मेन्यू से सुरक्षित बूट मोड में जाने का विकल्प देना चाहिए. यह विकल्प किसी ऐसे वर्कफ़्लो का इस्तेमाल करके दिया जाना चाहिए जो सामान्य बूट मोड से अलग हो.

9.14. ऑटोमोटिव व्हीकल सिस्टम आइसोलेशन

Android Automotive डिवाइस, वाहन के ज़रूरी सबसिस्टम के साथ डेटा शेयर करते हैं. ऐसा करने के लिए, वाहन के एचएएल का इस्तेमाल किया जाता है. ऐसा सीएएन बस जैसे वाहन के नेटवर्क से मैसेज भेजने और पाने के लिए किया जाता है.

Android फ़्रेमवर्क की लेयर के नीचे सुरक्षा से जुड़ी सुविधाएं लागू करके, डेटा के लेन-देन को सुरक्षित किया जा सकता है. इससे इन सबसिस्टम के साथ नुकसान पहुंचाने वाले या अनजाने में होने वाले इंटरैक्शन को रोका जा सकता है.

9.15. सदस्यता प्लान

"सदस्यता प्लान" का मतलब है, बिलिंग के लिए तय किए गए उस प्लान की जानकारी जिसे मोबाइल और इंटरनेट सेवा देने वाली कंपनी, SubscriptionManager.setSubscriptionPlans() को मुहैया कराती है.

लागू किए गए सभी डिवाइस:

  • [C-0-1] मोबाइल और इंटरनेट सेवा देने वाली उस कंपनी के ऐप्लिकेशन पर ही सदस्यता की योजनाओं को लौटाना ज़रूरी है जिन्होंने उन्हें मूल रूप से उपलब्ध कराया है.
  • [C-0-2] किसी दूसरी जगह से सदस्यता के प्लान का बैक अप नहीं लेना चाहिए और न ही उन्हें अपलोड करना चाहिए.
  • [C-0-3] आपको मोबाइल और इंटरनेट सेवा देने वाली उस कंपनी के ऐप्लिकेशन से सिर्फ़ SubscriptionManager.setSubscriptionOverrideCongested() जैसे बदलाव करने की अनुमति देनी होगी जो फ़िलहाल मान्य सदस्यता प्लान उपलब्ध करा रहा है.

10. सॉफ़्टवेयर के साथ काम करने से जुड़ी जांच

डिवाइस पर इस सेक्शन में बताए गए सभी टेस्ट पास करने ज़रूरी हैं. हालांकि, ध्यान रखें कि कोई भी सॉफ़्टवेयर जांच पैकेज पूरी तरह से विस्तृत नहीं होता है. इस वजह से, डिवाइस लागू करने वालों को इस बात का खास तौर पर सुझाव दिया जाता है कि वे Android ओपन सोर्स प्रोजेक्ट से मिले Android के रेफ़रंस और उसे लागू करने के अपने पसंदीदा तरीके में कम से कम संख्या में बदलाव करें. इससे ऐसी गड़बड़ियां पैदा होने का जोखिम कम हो जाएगा जिनकी वजह से डिवाइस में गड़बड़ी होती है और डिवाइस पर फिर से काम करने और संभावित अपडेट की ज़रूरत होती है.

10.1. कंपैटबिलिटी टेस्ट सुइट

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] डिवाइस पर मौजूद आखिरी शिपिंग सॉफ़्टवेयर का इस्तेमाल करके, Android ओपन सोर्स प्रोजेक्ट से मिले Android कंपैटबिलिटी टेस्ट सुइट (सीटीएस) को पास करना ज़रूरी है.

  • [C-0-2] सीटीएस में साफ़ तौर पर जानकारी न देने पर और रेफ़रंस सोर्स कोड के हिस्सों को फिर से लागू करने पर, यह पक्का करना ज़रूरी है कि यह साथ काम करता है या नहीं.

सीटीएस को इस तरह से डिज़ाइन किया गया है कि यह उपयोगकर्ता के डिवाइस पर चल सके. किसी भी सॉफ़्टवेयर की तरह, सीटीएस में भी गड़बड़ियां हो सकती हैं. सीटीएस का वर्शन, 'कंपैटबिलिटी डेफ़िनिशन' से अलग होगा. साथ ही, Android 9 के लिए सीटीएस के कई बदलाव रिलीज़ किए जा सकते हैं.

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-3] डिवाइस का सॉफ़्टवेयर पूरा होने के बाद, सीटीएस का सबसे नया वर्शन पास करना ज़रूरी है.

  • Android ओपन सोर्स ट्री में जहां तक संभव हो, रेफ़रंस इंप्लिमेंटेशन का इस्तेमाल करना चाहिए.

10.2. सीटीएस वेरिफ़ायर

सीटीएस वेरिफ़ायर, कंपैटबिलिटी टेस्ट सुइट के साथ शामिल है. इसे कोई व्यक्ति ऑपरेटर चलाकर ऐसे फ़ंक्शन की जांच कर सकता है जिसे ऑटोमेटेड सिस्टम (कार्रवाइयों को अपने-आप पूरा करने वाला सिस्टम) से टेस्ट नहीं किया जा सकता. जैसे, कैमरे और सेंसर के सही तरीके से काम करना.

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-1] सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी मामलों का सही तरीके से पालन करना ज़रूरी है.

CTS Verifier में कई तरह के हार्डवेयर की जांच की जा सकती है. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो ज़रूरी नहीं होते.

डिवाइस पर यह सुविधा लागू करना:

  • [C-0-2] उनके पास मौजूद हार्डवेयर की सभी जांचों को पास करना ज़रूरी है; उदाहरण के लिए, अगर किसी डिवाइस में एक्सीलरोमीटर है, तो उसे सीटीएस वेरिफ़ायर में एक्सलरोमीटर टेस्ट केस को सही तरीके से एक्ज़ीक्यूट करना होगा.

कम्पैटिबिलिटी डेफ़िनिशन वाले इस दस्तावेज़ के तहत वैकल्पिक के तौर पर बताई गई सुविधाओं के टेस्ट केस, स्किप किए जा सकते हैं या हटाए जा सकते हैं.

  • [C-0-2] जैसा कि ऊपर बताया गया है, हर डिवाइस और हर बिल्ड के लिए CTS Verifier को सही तरीके से चलाना ज़रूरी है. हालांकि, कई बिल्ड काफ़ी मिलते-जुलते होते हैं. इसलिए, यह उम्मीद की जाती है कि डिवाइस लागू करने वाले उन बिल्ड पर साफ़ तौर पर CTS Verifier नहीं चला पाएंगे जो बहुत ही साधारण हैं. खास तौर पर, ऐसी सुविधाओं को लागू करना जो सीटीएस पुष्टि करने वाले को सिर्फ़ शामिल स्थान-भाषा, ब्रैंडिंग वगैरह के सेट के हिसाब से पास करने के तरीके से अलग हैं. ऐसा हो सकता है कि सीटीएस वेरिफ़ायर टेस्ट को छोड़ दिया जाए.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

  • [C-0-1] डिवाइस पर, सिस्टम के सभी सॉफ़्टवेयर को बदलने का तरीका शामिल होना चाहिए. यह ज़रूरी नहीं है कि यह तरीका “लाइव” अपग्रेड करे. इसका मतलब है कि डिवाइस को रीस्टार्ट करने की ज़रूरत पड़ सकती है. किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि यह डिवाइस पर पहले से इंस्टॉल किए गए सॉफ़्टवेयर को पूरी तरह से बदल सके. उदाहरण के लिए, इनमें से कोई भी तरीका इस ज़रूरी शर्त को पूरा करेगा:

    • डिवाइस को फिर से चालू करके, “ओवर-द-एयर (ओटीए)” को ऑफ़लाइन अपडेट किया जा सकता है.
    • होस्ट पीसी से यूएसबी पर “Tethered” अपडेट होता है.
    • डिवाइस को फिर से चालू करके, “ऑफ़लाइन” अपडेट किया जाता है. साथ ही, हटाए जा सकने वाले स्टोरेज में सेव की गई फ़ाइल को अपडेट किया जाता है.

  • [C-0-2] अपडेट करने के लिए इस्तेमाल किए गए तरीके को, उपयोगकर्ता का डेटा वाइप किए बिना अपडेट काम करना चाहिए. इसका मतलब है कि अपडेट करने के तरीके में, ऐप्लिकेशन के निजी डेटा और ऐप्लिकेशन के शेयर किए गए डेटा को सुरक्षित रखना ज़रूरी है. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में, अपडेट करने का ऐसा तरीका शामिल है जो इस ज़रूरी शर्त को पूरा करता है.

अगर डिवाइस लागू करने के तरीके में 802.11 या ब्लूटूथ पैन (निजी क्षेत्र नेटवर्क) प्रोफ़ाइल जैसे बिना डेटा कनेक्शन वाले डेटा कनेक्शन के लिए सहायता शामिल है, तो वे:

  • [C-1-1] डिवाइस को फिर से चालू करके, ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड करने की सुविधा दी जानी चाहिए.

Android 6.0 और उसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइस पर, अपडेट करने के तरीके को इस बात की पुष्टि करनी चाहिए कि सिस्टम इमेज, ओटीए मिलने के बाद मिलने वाले अनुमानित नतीजे की बाइनरी इमेज के बराबर है. Android 5.1 के बाद जोड़े गए अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में ब्लॉक-आधारित ओटीए लागू करने की सुविधा इस ज़रूरी शर्त को पूरा करती है.

इसके अलावा, डिवाइस पर A/B सिस्टम अपडेट लागू होने चाहिए. एओएसपी इस सुविधा को बूट कंट्रोल एचएएल का इस्तेमाल करके लागू करता है.

अगर किसी डिवाइस को रिलीज़ किए जाने के बाद, उसे लागू करने के दौरान तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने से जुड़ी कोई गड़बड़ी मिलती है, तो:

  • [C-2-1] डिवाइस लागू करने वाले को सॉफ़्टवेयर अपडेट के ज़रिए इस गड़बड़ी को ठीक करना होगा. यह अपडेट, बताए गए तरीके के हिसाब से लागू किया जा सकता है.

Android में ऐसी सुविधाएं शामिल हैं जो डिवाइस के मालिक वाले ऐप्लिकेशन (मौजूद होने पर) को यह कंट्रोल करने की अनुमति देती हैं कि सिस्टम अपडेट इंस्टॉल किए जाएं या नहीं. अगर डिवाइस के लिए सिस्टम अपडेट सबसिस्टम android.software.device_admin की रिपोर्ट करता है, तो वे:

  • [C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में बदलावों का लॉग

इस रिलीज़ में 'कंपैटबिलिटी डेफ़िनिशन' में हुए बदलावों की खास जानकारी के लिए:

अलग-अलग सेक्शन में हुए बदलावों की खास जानकारी के लिए:

  1. शुरुआती जानकारी
  2. डिवाइस के टाइप
  3. सॉफ़्टवेयर
  4. ऐप्लिकेशन पैकेजिंग
  5. मल्टीमीडिया
  6. डेवलपर टूल और विकल्प
  7. हार्डवेयर पर काम करता है
  8. परफ़ॉर्मेंस और पावर
  9. सुरक्षा मॉडल
  10. सॉफ़्टवेयर के साथ काम करने से जुड़ी जांच
  11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
  12. दस्तावेज़ में बदलावों का लॉग
  13. हमसे संपर्क करें

12.1. बदलावों का लॉग देखने से जुड़ी सलाह

बदलावों को इस तरह मार्क किया गया है:

  • सीडीडी
    इसके साथ काम करने की ज़रूरी शर्तों में किए गए बड़े बदलाव.

  • Docs
    कॉस्मेटिक का इस्तेमाल करें या उससे जुड़े बदलाव करें.

बेहतर तरीके से देखने के लिए, अपने चेंजलॉग यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

13। हमसे संपर्क करें

आपके पास Android-कंपैटबिलिटी फ़ोरम में शामिल होकर, उनके बारे में साफ़ तौर पर जानकारी मांगने का विकल्प है. इसके अलावा, ऐसी किसी भी समस्या के बारे में भी बताया जा सकता है जो आपके हिसाब से इस दस्तावेज़ में शामिल नहीं है.