WindowManager एक्सटेंशन

Jetpack WindowManager लाइब्रेरी की मदद से, ऐप्लिकेशन डेवलपर, डिवाइस के नए नाप या आकार के हिसाब से ऐप्लिकेशन बना सकते हैं. साथ ही, मल्टी‑विंडो एनवायरमेंट के लिए भी ऐप्लिकेशन बनाए जा सकते हैं.

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

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

Extensions को .jar लाइब्रेरी में कंपाइल किया जाता है. इसके बाद, इसे डिवाइस के system_ext पार्टीशन में रखा जाता है. हालांकि, ऐसा तब किया जाता है, जब डिवाइस की मेकफ़ाइल में Extensions की सुविधा चालू हो.

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

$(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 Extensions को प्लैटफ़ॉर्म कोड की तरह, ऐप्लिकेशन प्रोसेस में लोड किया गया है.

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

यहां दी गई इमेज में, androidx.window.extensions या androidx.window.sidecar के इस्तेमाल का पता लगाने की लॉजिक दिखाया गया है.

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

Extensions मॉड्यूल

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

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

Extensions और Jetpack API

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

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

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

Extensions के वर्शन और अपडेट

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

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

Android प्लैटफ़ॉर्म का वर्शन WindowManager Extensions API लेवल androidx.window.extensions API वर्शन
Android 15 6 1.5.0 (जल्द आ रहा है)
Android 14 QPR3 5 1.4.0 (जल्द आ रहा है)
Android 14 QPR1 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

मौजूदा स्टेबल एपीआई (दायां कॉलम) में कोई सुविधा जोड़ने पर, Extensions API लेवल (बीच वाला कॉलम) बढ़ जाता है.

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

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

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

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

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

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

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

परफ़ॉर्मेंस

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

मॉड्यूल

ऐक्टिविटी एम्बेड करना

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

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

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

डिवाइस के किसी खास कॉन्फ़िगरेशन की ज़रूरत नहीं है. हालांकि, Extensions मॉड्यूल को चालू करना ज़रूरी है. इसके बारे में, Extensions module distribution सेक्शन में बताया गया है. मल्टी‑विंडो मोड की सुविधा वाले सभी डिवाइसों पर, Extensions की सुविधा चालू करना सही है. Android के आने वाले वर्शन में, आम तौर पर इस्तेमाल होने वाले हैंडहेल्ड और बड़ी स्क्रीन वाले डिवाइसों के कॉन्फ़िगरेशन के लिए, Extensions की सुविधा ज़रूरी हो सकती है.

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

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

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

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

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

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

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

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

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

  • Extensions मॉड्यूल को चालू करें. इसके बारे में, Extensions module distribution सेक्शन में बताया गया है.

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

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

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

  • 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 में, स्थिति के आइडेंटिफ़ायर की जानकारी दें. इसका इस्तेमाल Extensions करेगा.
    • ऐप्लिकेशन के लिए, स्थिति के आइडेंटिफ़ायर को उपलब्ध कराने के लिए, इसे 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 में, स्थिति के आइडेंटिफ़ायर की जानकारी दें. इसका इस्तेमाल Extensions करेगा. हालांकि, ऐसा तब किया जाता है, जब आइडेंटिफ़ायर को ऐप्लिकेशन के लिए उपलब्ध कराना हो.
    • ऐप्लिकेशन के लिए, स्थिति के आइडेंटिफ़ायर को उपलब्ध कराने के लिए, इसे com.android.internal.R.array.config_deviceStatesAvailableForAppRequests में जोड़ें.

पुष्टि

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

सीटीएस टेस्ट

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

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