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 लाइब्रेरी में इस्तेमाल किए जाने पर, मॉड्यूल को ऐप्लिकेशन प्रोसेस के हिस्से के तौर पर लोड किया जाता है और उन्हें एक्ज़ीक्यूट किया जाता है. इससे, यह काम, क्लाइंट-साइड फ़्रेमवर्क कोड की तरह ही होता है, जैसा कि इस इमेज में दिखाया गया है:

पहली इमेज. ऐप्लिकेशन प्रोसेस में लोड किए गए WindowManager एक्सटेंशन, प्लैटफ़ॉर्म कोड से मिलते-जुलते हैं.

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

इस डायग्राम में, androidx.window.extensions या androidx.window.sidecar का इस्तेमाल तय करने का लॉजिक बताया गया है.

दूसरी इमेज. androidx.window.extensions या androidx.window.sidecar को ऐक्सेस करने के लिए डिसीज़न ट्री.

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

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

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

एक्सटेंशन और Jetpack API

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 एपीआई वर्शन की सूची दी गई है.

Android प्लैटफ़ॉर्म का वर्शन WindowManager एक्सटेंशन एपीआई लेवल androidx.window.extensions एपीआई वर्शन
Android 15 6 1.5.0 (जल्द आ रहा है)
Android 14 क्यूपीआर3 5 1.4.0 (जल्द आ रहा है)
Android 14 क्यूपीआर1 4 1.3.0
Android 14 3 1.2.0
Android 13 QPR3 2 1.1.0
Android 13 1 1.0.0
Android 12L 1 1.0.0

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

पीछे और आगे साथ काम करने की सुविधा

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

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

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

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

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

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

परफ़ॉर्मेंस

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

मॉड्यूल

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

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

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

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

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

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

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

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

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

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

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

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

  • device_state_configuration.xml में डिवाइस की स्थितियों को कॉन्फ़िगर करें, ताकि DeviceStateManagerService उनका इस्तेमाल कर सके. रेफ़रंस के लिए, 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 को ये काम करने होंगे:

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

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