WindowManager एक्सटेंशन

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

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

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

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

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

$(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 का इस्तेमाल करने का लॉजिक दिखाया गया है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

परफ़ॉर्मेंस

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

मॉड्यूल

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 में उनसे जुड़ी स्थितियां बताएं.

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

  • com.android.internal.R.array.config_rearDisplayDeviceStates के लिए, DeviceStateManager में मौजूद राज्यों की सूची बनाएं.
  • 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 में राज्य का आइडेंटिफ़ायर जोड़ें.

पुष्टि

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

सीटीएस टेस्ट

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

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