WindowManager Extensions मॉड्यूल

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

पहली इमेज. ऐप्लिकेशन प्रोसेस में लोड किए गए एक्सटेंशन.

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

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

दूसरी इमेज. 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 के पुराने वर्शन के साथ काम करना जारी रखना चाहिए. ऐसा इसलिए, ताकि आगे आने वाले समय में भी एक्सटेंशन काम करते रहें. यह पक्का करने के लिए, Extensions API के किसी भी नए वर्शन में सिर्फ़ नए एपीआई जोड़े जाते हैं और पुराने एपीआई नहीं हटाए जाते. इस वजह से, WindowManager के पुराने वर्शन वाले ऐप्लिकेशन, Extensions API के पुराने वर्शन का इस्तेमाल जारी रख सकते हैं. इन ऐप्लिकेशन को Extensions API के पुराने वर्शन के हिसाब से कंपाइल किया गया था.

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

परफ़ॉर्मेंस

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

मॉड्यूल

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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