WindowManager एक्सटेंशन

Jetpack WindowManager लाइब्रेरी की मदद से, ऐप्लिकेशन डेवलपर नए डिवाइस फ़ॉर्म फ़ैक्टर और कई विंडो वाले एनवायरमेंट के साथ काम कर सकते हैं.

WindowManager एक्सटेंशन (एक्सटेंशन), Android प्लैटफ़ॉर्म का एक ऑप्ट-इन मॉड्यूल है. इससे, Jetpack WindowManager की कई सुविधाएं चालू की जा सकती हैं. इस मॉड्यूल को frameworks/base/libs/WindowManager/Jetpack में AOSP में लागू किया गया है और इसे उन डिवाइसों पर शिप किया जाता है जिन पर WindowManager की सुविधाएं काम करती हैं.

एक्सटेंशन मॉड्यूल का डिस्ट्रिब्यूशन

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

किसी डिवाइस पर एक्सटेंशन चालू करने के लिए, प्रॉडक्ट डिवाइस के makefile में यह जानकारी जोड़ें:

$(call inherit-product, $(SRC_TARGET_DIR)/product/window_extensions.mk)

इससे डिवाइस पर androidx.window.extensions और androidx.window.sidecar पैकेज चालू हो जाते हैं. साथ ही, persist.wm.extensions.enabled प्रॉपर्टी सेट हो जाती है. इन पैकेज को मेकफ़ाइल में शामिल करने से, etc/permissions/ में भी एलान किए जाते हैं. इससे, ये एलान ऐप्लिकेशन प्रोसेस के लिए उपलब्ध हो जाते हैं. आम तौर पर, जब Jetpack WindowManager लाइब्रेरी का इस्तेमाल किया जाता है, तो मॉड्यूल को ऐप्लिकेशन प्रोसेस के हिस्से के तौर पर, रनटाइम पर लोड और चलाया जाता है. इससे, इसका काम क्लाइंट-साइड फ़्रेमवर्क कोड की तरह हो जाता है, जैसा कि इस इमेज में दिखाया गया है:

androidx.window.extensions मॉड्यूल, एक्सटेंशन का मौजूदा मॉड्यूल है. इसे फ़िलहाल डेवलप किया जा रहा है. androidx.window.sidecar मॉड्यूल एक लेगसी मॉड्यूल है, जिसे Jetpack WindowManager के शुरुआती वर्शन के साथ काम करने के लिए शामिल किया गया था. हालांकि, अब साइडकार को अपडेट नहीं किया जा रहा है.

नीचे दिए गए इलस्ट्रेशन में, androidx.window.extensions या androidx.window.sidecar के इस्तेमाल का लॉजिक दिखाया गया है.

एक्सटेंशन मॉड्यूल

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

• गतिविधि को एम्बेड करना
• विंडो के लेआउट की जानकारी
• विंडो का एरिया

अगर डिवाइस का हार्डवेयर, उन सुविधाओं के साथ काम नहीं करता है जिनके लिए एक्सटेंशन लागू किए गए हैं, तो OEM, WindowExtensions इंटरफ़ेस में डिफ़ॉल्ट या स्टब के तौर पर लागू किए गए तरीकों के साथ, शून्य कॉम्पोनेंट या कॉम्पोनेंट उपलब्ध करा सकता है. ऐसा तब तक किया जा सकता है, जब तक कि संगतता की परिभाषा वाले दस्तावेज़ (सीडीडी) 7.1.1.1 में, खास तौर पर उस सुविधा का अनुरोध न किया गया हो.

एक्सटेंशन और Jetpack एपीआई

WindowManager एक्सटेंशन मॉड्यूल, सार्वजनिक प्लैटफ़ॉर्म एपीआई के साथ-साथ अपना एपीआई प्लैटफ़ॉर्म भी उपलब्ध कराता है. एक्सटेंशन मॉड्यूल को सार्वजनिक तौर पर, ऐसी androidx.window.extensions Jetpack लाइब्रेरी में डेवलपर के लिए उपलब्ध नहीं कराया जाता है, ताकि Jetpack WindowManager (androidx.window) इसे कंपाइल करने के समय लिंक कर सके. एक्सटेंशन एपीआई के प्लैटफ़ॉर्म पर आम तौर पर, कम लेवल के एपीआई उपलब्ध होते हैं.

एक्सटेंशन के ज़रिए उपलब्ध कराए गए एपीआई का इस्तेमाल, सिर्फ़ Jetpack WindowManager लाइब्रेरी के लिए किया जाना चाहिए. एक्सटेंशन एपीआई को ऐप्लिकेशन डेवलपर सीधे तौर पर कॉल नहीं कर सकते. सही तरीके से काम करने के लिए, एक्सटेंशन लाइब्रेरी को Gradle बिल्ड फ़ाइल में किसी ऐप्लिकेशन के लिए डिपेंडेंसी के तौर पर नहीं जोड़ा जाना चाहिए. एक्सटेंशन लाइब्रेरी को सीधे किसी ऐप्लिकेशन में पहले से कॉम्पाइल करने से बचें. इसके बजाय, रनटाइम लोडिंग का इस्तेमाल करें, ताकि पहले से कॉम्पाइल की गई और रनटाइम में उपलब्ध एक्सटेंशन क्लास को एक साथ लोड करने से बचा जा सके.

Jetpack WindowManager (androidx.window) को ऐप्लिकेशन की डिपेंडेंसी के तौर पर जोड़ा जाना चाहिए. यह डेवलपर के लिए सार्वजनिक एपीआई उपलब्ध कराता है. इनमें WindowManager एक्सटेंशन की सुविधाएं भी शामिल हैं. WindowManager लाइब्रेरी, ऐप्लिकेशन प्रोसेस में एक्सटेंशन को अपने-आप लोड करती है. साथ ही, यह लोअर-लेवल के एक्सटेंशन एपीआई को हाईअर-लेवल के एब्स्ट्रैक्शन और ज़्यादा फ़ोकस वाले इंटरफ़ेस में रैप करती है. WindowManager Jetpack API, आधुनिक Android ऐप्लिकेशन डेवलपमेंट के स्टैंडर्ड के मुताबिक होते हैं. इनका मकसद, AndroidX की अन्य लाइब्रेरी का इस्तेमाल करने वाले कोडबेस के साथ अच्छी तरह से इंटिग्रेट करके, आसानी से इंटरऑपरेबल होने की सुविधा देना है.

एक्सटेंशन के वर्शन और अपडेट

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

यहां दी गई टेबल में, Android के अलग-अलग वर्शन के लिए androidx.window.extensions एपीआई के वर्शन की सूची दी गई है.

जब भी मौजूदा स्टैबल एपीआई प्लैटफ़ॉर्म (राइट कॉलम) में कोई बदलाव होता है, तो एक्सटेंशन एपीआई लेवल (सेंटर कॉलम) में भी बदलाव होता है.

पुराने और नए सिस्टम के साथ काम करने की सुविधा

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

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

WindowManager एक्सटेंशन को system_ext मॉड्यूल के तौर पर लागू किया जाता है. यह एक्सटेंशन की सुविधाओं को लागू करने के लिए, WindowManager कोर, DeviceStateManager, और अन्य सिस्टम सेवाओं को कॉल करने के लिए, निजी प्लैटफ़ॉर्म एपीआई का इस्तेमाल करता है.

ऐसा हो सकता है कि Android के उस वर्शन के रिलीज़ होने से पहले, एक्सटेंशन के रिलीज़ होने से पहले के वर्शन के साथ काम न कर पाएं जिस पर एक्सटेंशन के वर्शन फ़ाइनल किए जाते हैं. यह रिलीज़, हर तीन महीने या साल में होती है. एक्सटेंशन एपीआई का पूरा इतिहास, रिलीज़ शाखा window:extensions:extensions एपीआई टेक्स्ट फ़ाइलों में देखा जा सकता है.

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

सीटीएस की पुष्टि से यह पक्का होता है कि डिवाइस पर एक्सटेंशन एपीआई के एलान किए गए किसी भी वर्शन के लिए, उस वर्शन और पिछले वर्शन के सभी एपीआई मौजूद हों और काम कर रहे हों.

परफ़ॉर्मेंस

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

मॉड्यूल

गतिविधि एम्बेड करना

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

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

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

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

विंडो लेआउट की जानकारी

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

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

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

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

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

फ़ोल्ड करने की सुविधा को लागू करने के लिए, OEM को ये काम करने होंगे:

• DeviceStateManagerService में इस्तेमाल करने के लिए, device_state_configuration.xml में डिवाइस की स्थितियों को कॉन्फ़िगर करें. रेफ़रंस के लिए, DeviceStateProviderImpl.java देखें.

  अगर डिफ़ॉल्ट रूप से लागू किए गए DeviceStateProvider या DeviceStatePolicy, डिवाइस के लिए सही नहीं हैं, तो कस्टम तरीके से लागू करने का विकल्प चुना जा सकता है.

• एक्सटेंशन मॉड्यूल के डिस्ट्रिब्यूशन सेक्शन में बताए गए तरीके से, एक्सटेंशन मॉड्यूल को चालू करें.

• com.android.internal.R.string.config_display_features स्ट्रिंग रिसॉर्स में डिसप्ले की सुविधाओं की जगह की जानकारी दें (आम तौर पर, डिवाइस ओवरले में frameworks/base/core/res/res/values/config.xml में).

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

  <type>-[<left>,<top>,<right>,<bottom>]

  type, fold या hinge हो सकता है. left, top, right, और bottom की वैल्यू, डिसप्ले कोऑर्डिनेट के स्पेस में पूर्णांक पिक्सल कोऑर्डिनेट होती हैं. ये वैल्यू, डिसप्ले के सामान्य ओरिएंटेशन में होती हैं. कॉन्फ़िगरेशन स्ट्रिंग में, एक से ज़्यादा डिसप्ले फ़ीचर हो सकते हैं. इन्हें सेमीकोलन लगाकर अलग किया जाता है.

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

  <!-- Jetpack WindowManager display features -->
  <string name="config_display_features" translatable="false">fold-[1000,0,1000,2000]</string>
  

• DeviceStateManager में इस्तेमाल किए गए डिवाइस की इंटरनल स्थिति के आइडेंटिफ़ायर और com.android.internal.R.array.config_device_state_postures में डेवलपर को भेजी गई पब्लिक स्टेटस के कॉन्स्टेंट के बीच मैपिंग तय करें.

  हर एंट्री के लिए यह फ़ॉर्मैट इस्तेमाल करें:

  <device_specific_state_identifier>:<Jetpack WindowManager state identifier>

  राज्य के आइडेंटिफ़ायर के तौर पर ये इस्तेमाल किए जा सकते हैं:

  • COMMON_STATE_NO_FOLDING_FEATURES = 1: राज्य में ऐसी कोई फ़ोल्डिंग सुविधा नहीं है जिसकी शिकायत की जा सके. उदाहरण के लिए, यह एक सामान्य फ़ोल्डिंग डिवाइस की बंद स्थिति हो सकती है, जिसमें मुख्य स्क्रीन अंदर की ओर हो.
  • COMMON_STATE_HALF_OPENED = 2: फ़ोल्ड करने की सुविधा आधी खुली है.
  • COMMON_STATE_FLAT = 3: फ़ोल्ड करने की सुविधा, फ़्लैट है. उदाहरण के लिए, यह आम तौर पर, अंदर की ओर फ़ोल्ड होने वाले डिवाइस की खुली हुई स्थिति हो सकती है, जिसमें मुख्य स्क्रीन अंदर की ओर हो.
  • COMMON_STATE_USE_BASE_STATE = 1000: Android 14 में, एक वैल्यू का इस्तेमाल उन एमुलेट की गई स्थितियों के लिए किया जा सकता है जहां हिंज की स्थिति, बुनियादी स्थिति का इस्तेमाल करके तय की जाती है. इस बारे में CommonFoldingFeature.java में बताया गया है

  ज़्यादा जानकारी के लिए, DeviceStateManager.DeviceStateCallback#onBaseStateChanged(int) देखें.

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

  <!-- Map of System DeviceState supplied by DeviceStateManager to WindowManager posture.-->
  <string-array name="config_device_state_postures" translatable="false">
    <item>0:1</item>    <!-- CLOSED       : COMMON_STATE_NO_FOLDING_FEATURES -->
    <item>1:2</item>    <!-- HALF_OPENED  : COMMON_STATE_HALF_OPENED -->
    <item>2:3</item>    <!-- OPENED       : COMMON_STATE_FLAT -->
    <item>3:1</item>    <!-- REAR_DISPLAY : COMMON_STATE_NO_FOLDING_FEATURES -->
    <item>4:1000</item> <!-- CONCURRENT   : COMMON_STATE_USE_BASE_STATE -->
  </string-array>
  

विंडो का क्षेत्र

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

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

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

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

फ़ोल्ड करने की सुविधा को लागू करने के लिए, OEM को ये काम करने होंगे:

• DeviceStateManagerService में इस्तेमाल करने के लिए, device_state_configuration.xml में डिवाइस की स्थितियों को कॉन्फ़िगर करें. ज़्यादा जानकारी के लिए, DeviceStateProviderImpl.java देखें.

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

• फ़ोल्ड किए जा सकने वाले ऐसे डिवाइसों के लिए जिनमें ओपन या फ़्लैट मोड काम करता है, com.android.internal.R.array.config_openDeviceStates में उनसे जुड़े स्टेटस आइडेंटिफ़ायर की जानकारी दें.

• फ़ोल्ड किए जा सकने वाले ऐसे डिवाइसों के लिए जिनमें फ़ोल्ड किए गए स्टेटस काम करते हैं, com.android.internal.R.array.config_foldedDeviceStates में उनसे जुड़े स्टेटस आइडेंटिफ़ायर की सूची बनाएं.

• ऐसे इन-फ़ोल्डिंग डिवाइसों के लिए जिनमें आधा फ़ोल्ड किया जा सकता है (जैसे, लैपटॉप की तरह आधा हिंज खुला हो), com.android.internal.R.array.config_halfFoldedDeviceStates में उन स्थितियों की सूची बनाएं.

• जिन डिवाइसों पर रियर डिसप्ले मोड काम करता है उनके लिए:

  • DeviceStateManager के लिए, com.android.internal.R.array.config_rearDisplayDeviceStates में उन स्थितियों की सूची बनाएं.
  • com.android.internal.R.string.config_rearDisplayPhysicalAddress में, पीछे की स्क्रीन का पता बताएं.
  • com.android.internal.R.integer.config_deviceStateRearDisplay में राज्य का आइडेंटिफ़ायर डालें, ताकि एक्सटेंशन इसका इस्तेमाल कर सकें.
  • ऐप्लिकेशन के लिए उपलब्ध कराने के लिए, राज्य का आइडेंटिफ़ायर com.android.internal.R.array.config_deviceStatesAvailableForAppRequests में जोड़ें.

• Android 14 पर, ड्यूअल (एक साथ) डिसप्ले मोड की सुविधा वाले डिवाइसों के लिए:

  • com.android.internal.R.bool.config_supportsConcurrentInternalDisplays को true पर सेट करें.
  • com.android.internal.R.config_deviceStateConcurrentRearDisplay में, पीछे की स्क्रीन का पता बताएं.
  • अगर आइडेंटिफ़ायर को ऐप्लिकेशन के लिए उपलब्ध कराना है, तो com.android.internal.R.integer.config_deviceStateConcurrentRearDisplay में राज्य का आइडेंटिफ़ायर डालें, ताकि एक्सटेंशन इसका इस्तेमाल कर सकें.
  • ऐप्लिकेशन के लिए उपलब्ध कराने के लिए, राज्य का आइडेंटिफ़ायर com.android.internal.R.array.config_deviceStatesAvailableForAppRequests में जोड़ें.

पुष्टि करें

OEM को यह पक्का करना होगा कि उन्होंने इस सुविधा को सही तरीके से लागू किया है, ताकि सामान्य स्थितियों में डिवाइस सही तरीके से काम करे. सीटीएस टेस्ट और Jetpack WindowManager का इस्तेमाल करने वाले टेस्ट, OEMs के लिए उपलब्ध हैं. इनका इस्तेमाल, लागू करने की जांच के लिए किया जाता है.

सीटीएस टेस्ट

सीटीएस टेस्ट चलाने के लिए, सीटीएस टेस्ट चलाना लेख पढ़ें. Jetpack WindowManager से जुड़ी सीटीएस जांच, cts/tests/framework/base/windowmanager/jetpack/ में मौजूद हैं. टेस्ट मॉड्यूल का नाम CtsWindowManagerJetpackTestCases है.

WindowManager की जांच

Jetpack WindowManager के टेस्ट डाउनलोड करने के लिए, Android Jetpack के निर्देशों का पालन करें. ये टेस्ट, विंडो लाइब्रेरी में window:window मॉड्यूल में मौजूद होते हैं: window/window/src/androidTest/.

कमांड-लाइन से window:window मॉड्यूल के लिए डिवाइस टेस्ट चलाने के लिए, यह तरीका अपनाएं:

1. ऐसा डिवाइस प्लग-इन करें जिसमें 'डेवलपर के लिए सेटिंग और टूल' और यूएसबी डीबग करने की सुविधा चालू हो.
2. कंप्यूटर को डिवाइस को डीबग करने की अनुमति दें.
3. androidx रिपॉज़िटरी की रूट डायरेक्ट्री में एक शेल खोलें.
4. डायरेक्ट्री को framework/support में बदलें.
5. यह कमांड चलाएं: ./gradlew window:window:connectedAndroidTest.
6. नतीजों का विश्लेषण करें.

Android Studio से टेस्ट चलाने के लिए, यह तरीका अपनाएं:

1. Android Studio खोलें.
2. ऐसा डिवाइस प्लग-इन करें जिसमें 'डेवलपर के लिए सेटिंग और टूल' और यूएसबी डीबग करने की सुविधा चालू हो.
3. कंप्यूटर को डिवाइस को डीबग करने की अनुमति दें.
4. विंडो मॉड्यूल की विंडो लाइब्रेरी में किसी टेस्ट पर जाएं.
5. कोई टेस्ट क्लास खोलें और एडिटर की दाईं ओर मौजूद हरे ऐरो का इस्तेमाल करके उसे चलाएं.

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

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