सुझाए गए तरीके

इस पेज पर, एक से ज़्यादा डिसप्ले के साथ काम करने के बारे में सुझाव दिए गए हैं.

फ़ोल्डेबल और मल्टी-स्क्रीन वाले डिवाइसों के लिए ऐप्लिकेशन

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

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

डिसप्ले ऐक्सेस करने पर पाबंदी लगाना

अगर डिवाइस के कॉन्फ़िगरेशन के लिए, एक या उससे ज़्यादा डिसप्ले के ऐक्सेस पर पाबंदी लगाना ज़रूरी है, तो हमारा सुझाव है कि डिसप्ले को निजी के तौर पर तय करने के लिए, Display#FLAG_PRIVATE फ़्लैग का इस्तेमाल करें. इस फ़्लैग के इस्तेमाल से, मालिक के अलावा किसी और को डिसप्ले में कॉन्टेंट जोड़ने से रोका जा सकता है. अगर मालिक के अलावा कोई और व्यक्ति, गतिविधि लॉन्च करने या कोई विंडो जोड़ने की कोशिश करता है, तो SecurityException ट्रिगर होता है. अगर सिस्टम के पास डिसप्ले का मालिकाना हक है, तो सिस्टम विंडो जोड़ सकता है और गतिविधियां लॉन्च कर सकता है.

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

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

ज़्यादा जानकारी के लिए, यह देखें:

  • ActivityStackSupervisor#isCallerAllowedToLaunchOnDisplay
  • ActivityDisplay#isUidPresent
  • DisplayManagerService#isUidPresentOnDisplay

शर्त के हिसाब से, गतिविधि लॉन्च करने की सुविधा को कंट्रोल करने के लिए, LaunchParamsController का इस्तेमाल करें. यह सभी गतिविधि लॉन्च को इंटरसेप्ट करता है और सिस्टम कॉम्पोनेंट को लॉन्च के लिए इस्तेमाल किए जाने वाले पैरामीटर में बदलाव करने की अनुमति देता है. यह system_server में उपलब्ध है.

डिसप्ले विंडोइंग सेटिंग और सिस्टम डेकोरेशन कॉन्फ़िगर करना

सिस्टम डेकोरेशन को हर डिसप्ले के लिए DisplayWindowSettings में कॉन्फ़िगर किया जा सकता है. डिवाइस को लागू करने के दौरान, /data/system/display_settings.xml में डिफ़ॉल्ट कॉन्फ़िगरेशन दिया जा सकता है.

इस वैल्यू से यह तय होता है कि किसी डिसप्ले पर सिस्टम डेकोरेशन (लॉन्चर, वॉलपेपर, नेविगेशन बार, और अन्य डेकोर विंडो) और आईएमई दिखते हैं या नहीं. ज़्यादा जानकारी के लिए, DisplayWindowSettings#shouldShowSystemDecorsLocked और DisplayWindowSettings#shouldShowImeLocked देखें.

डिसप्ले की पहचान करने के लिए, कोई यूनीक आईडी (डिफ़ॉल्ट तौर पर DisplayInfo#uniqueId का इस्तेमाल किया जाता है) या हार्डवेयर डिसप्ले के लिए फ़िज़िकल पोर्ट आईडी का इस्तेमाल करें. इसके लिए, DisplayInfo#address देखें.

उदाहरण के लिए, डिसप्ले कॉन्फ़िगरेशन के इस उदाहरण में, सिम्युलेटेड डिसप्ले पर सिस्टम डेकोरेशन और आईएमई की सुविधा चालू की गई है:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<display-settings>
<config identifier="0" />
<display
  name="overlay:1"
  shouldShowSystemDecors="true"
  shouldShowIme="true" />
</display-settings>

ऊपर दिए गए उदाहरण में, नाम एट्रिब्यूट में डिसप्ले की पहचान के लिए uniqueId का इस्तेमाल किया गया है. सिम्युलेटेड डिसप्ले के लिए, यह overlay:1 है. बिल्ट-इन डिसप्ले के लिए, सैंपल वैल्यू "local:45354385242535243453" हो सकती है. एक और विकल्प है कि हार्डवेयर पोर्ट की जानकारी का इस्तेमाल किया जाए और identifier="1" को DisplayWindowSettings#IDENTIFIER_PORTके हिसाब से सेट किया जाए. इसके बाद, नाम को "port:<port_id>"फ़ॉर्मैट में अपडेट किया जाए:

<?xmlversion='1.0' encoding='utf-8' standalone='yes' ?>
<display-settings>
<config identifier="1" />
<display
  name="port:12345"
  shouldShowSystemDecors="true"
  shouldShowIme="true" />
</display-settings>

ज़्यादा जानकारी के लिए, स्टैटिक डिसप्ले आइडेंटिफ़ायर देखें.

ज़्यादा जानकारी के लिए, यह देखें:

मिररिंग और होस्टिंग टास्क के बीच डिसप्ले स्विच करना

Android 17 और इसके बाद के वर्शन में, DisplayManager uses the FLAG_ALLOWS_CONTENT_MODE_SWITCH फ़्लैग का इस्तेमाल करके यह कंट्रोल करता है कि रन टाइम में कोई डिसप्ले, मिररिंग और होस्टिंग टास्क के बीच स्विच करता है या नहीं. डिफ़ॉल्ट तौर पर, यह फ़्लैग बाहरी डिसप्ले के लिए चालू होता है और अन्य सभी डिसप्ले के लिए बंद होता है.

FLAG_ALLOWS_CONTENT_MODE_SWITCH मौजूद होने पर, DisplayManager, android.provider.Settings.Secure.MIRROR_BUILT_IN_DISPLAY सुरक्षित सेटिंग की निगरानी करता है. इससे यह तय होता है कि मिररिंग या होस्टिंग टास्क करने हैं या नहीं. यह डिफ़ॉल्ट लॉजिक है. हालांकि, ओईएम इस व्यवहार को पसंद के मुताबिक बना सकते हैं.

डिसप्ले टोपोलॉजी और पॉइंटर की गतिविधि

Android 17 और इसके बाद के वर्शन में, डिसप्ले टोपोलॉजी, डिसप्ले की रिलेटिव पोज़िशन तय करती है. साथ ही, माउस पॉइंटर की गतिविधि को टोपोलॉजी में मौजूद डिसप्ले के खास सेट तक सीमित करती है.

WindowManager यह तय करता है कि किसी डिसप्ले को टोपोलॉजी में शामिल करना है या नहीं. इसके लिए, वह DisplayManagerInternal.onDisplayBelongToTopologyChanged को कॉल करता है. DisplayManager , डिसप्ले जोड़ने से पहले DisplayTopologyCoordinator.isDisplayAllowedInTopology की जांच करता है. डिफ़ॉल्ट तौर पर, अगर लोकल डिसप्ले, टास्क होस्ट कर सकते हैं, तो सिस्टम उन्हें जोड़ता है.

अगर एक से ज़्यादा सार्वजनिक डिसप्ले, टास्क होस्ट कर सकते हैं, तो डिफ़ॉल्ट डिसप्ले को शामिल करने का फ़ैसला, shouldIncludeDefaultDisplayInTopology बूलियन प्रोवाइडर लेता है. इसे DisplayTopologyCoordinator को पास किया जाता है. अगर डिफ़ॉल्ट डिसप्ले, टास्क होस्ट करने वाला इकलौता सार्वजनिक डिसप्ले है, तो यह हमेशा टोपोलॉजी में होता है. AOSP में, बूलियन प्रोवाइडर, true सिर्फ़ तब दिखाता है, जब डिफ़ॉल्ट डिसप्ले, डेस्कटॉप विंडोइंग की सुविधा के साथ काम करता है या सुरक्षित सेटिंग Settings.Secure.INCLUDE_DEFAULT_DISPLAY_IN_TOPOLOGY, true पर सेट होती है.

ऐप्लिकेशन, DisplayManager.getDisplayTopology का इस्तेमाल करके, मौजूदा टोपोलॉजी के बारे में क्वेरी करते हैं. साथ ही, DisplayManager.registerTopologyListener के साथ लिसनर रजिस्टर करके, टोपोलॉजी में होने वाले बदलावों पर प्रतिक्रिया देते हैं.