समर्थन प्रदर्शित करें

इन प्रदर्शन-विशिष्ट क्षेत्रों में किए गए अपडेट नीचे दिए गए हैं:

गतिविधियों और प्रदर्शनों का आकार बदलें

यह इंगित करने के लिए कि कोई ऐप मल्टी-विंडो मोड या आकार बदलने का समर्थन नहीं कर सकता है, गतिविधियाँ resizeableActivity=false विशेषता का उपयोग करती हैं। गतिविधियों का आकार बदलने पर ऐप्स द्वारा सामना की जाने वाली सामान्य समस्याओं में शामिल हैं:

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

एंड्रॉइड 7 (और उच्चतर) में, एक ऐप को हमेशा पूर्ण स्क्रीन मोड में चलाने के लिए resizeableActivity=false सेट किया जा सकता है। इस मामले में, प्लेटफ़ॉर्म गैर-आकार बदलने योग्य गतिविधियों को विभाजित स्क्रीन में जाने से रोकता है। यदि उपयोगकर्ता पहले से ही स्प्लिट-स्क्रीन मोड में रहते हुए लॉन्चर से एक गैर-आकार बदलने योग्य गतिविधि को शुरू करने का प्रयास करता है, तो प्लेटफ़ॉर्म स्प्लिट-स्क्रीन मोड से बाहर निकल जाता है और गैर-आकार बदलने योग्य गतिविधि को पूर्ण-स्क्रीन मोड में लॉन्च करता है।

वे ऐप्स जो मैनिफ़ेस्ट में स्पष्ट रूप से इस विशेषता को false पर सेट करते हैं, उन्हें मल्टी-विंडो मोड में लॉन्च नहीं किया जाना चाहिए, जब तक कि संगतता मोड लागू न हो:

  • प्रक्रिया पर समान कॉन्फ़िगरेशन लागू किया जाता है, जिसमें सभी गतिविधियाँ और गैर-गतिविधि घटक शामिल होते हैं।
  • लागू कॉन्फ़िगरेशन ऐप-संगत डिस्प्ले के लिए सीडीडी आवश्यकताओं को पूरा करता है।

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

डिफ़ॉल्ट कार्यान्वयन निम्नलिखित नीति लागू करता है:

जब किसी गतिविधि को android:resizeableActivity विशेषता के उपयोग के माध्यम से मल्टी-विंडो के साथ असंगत घोषित किया जाता है और जब वह गतिविधि नीचे वर्णित शर्तों में से एक को पूरा करती है, तो जब लागू स्क्रीन कॉन्फ़िगरेशन को बदलना होगा, तो गतिविधि और प्रक्रिया मूल कॉन्फ़िगरेशन के साथ सहेजी जाती है और उपयोगकर्ता को अद्यतन स्क्रीन कॉन्फ़िगरेशन का उपयोग करने के लिए ऐप प्रक्रिया को फिर से लॉन्च करने की सुविधा प्रदान की जाती है।

  • android:screenOrientation
  • ऐप में एपीआई स्तर को लक्षित करके डिफ़ॉल्ट अधिकतम या न्यूनतम पहलू अनुपात होता है या पहलू अनुपात को स्पष्ट रूप से घोषित किया जाता है

यह आंकड़ा घोषित पहलू अनुपात के साथ एक गैर-आकार बदलने योग्य गतिविधि प्रदर्शित करता है। डिवाइस को मोड़ते समय, उपयुक्त लेटरबॉक्सिंग का उपयोग करके पहलू अनुपात को बनाए रखते हुए क्षेत्र को फिट करने के लिए विंडो को नीचे की ओर छोटा किया जाता है। इसके अलावा, हर बार गतिविधि के लिए प्रदर्शन क्षेत्र बदले जाने पर उपयोगकर्ता को गतिविधि पुनः आरंभ करने का विकल्प प्रदान किया जाता है।

डिवाइस को खोलते समय, गतिविधि का कॉन्फ़िगरेशन, आकार और पहलू अनुपात नहीं बदलता है, लेकिन गतिविधि को पुनरारंभ करने का विकल्प प्रदर्शित होता है।

जब resizeableActivity सेट नहीं होती है (या इसे true पर सेट किया जाता है), तो ऐप पूरी तरह से आकार बदलने का समर्थन करता है।

कार्यान्वयन

निश्चित अभिविन्यास या पहलू अनुपात के साथ एक गैर-आकार बदलने योग्य गतिविधि को कोड में आकार संगतता मोड (एससीएम) कहा जाता है। शर्त ActivityRecord#shouldUseSizeCompatMode() में परिभाषित की गई है। जब कोई SCM गतिविधि लॉन्च की जाती है, तो स्क्रीन-संबंधित कॉन्फ़िगरेशन (जैसे आकार या घनत्व) अनुरोधित ओवरराइड कॉन्फ़िगरेशन में तय हो जाता है, इसलिए गतिविधि अब वर्तमान डिस्प्ले कॉन्फ़िगरेशन पर निर्भर नहीं होती है।

यदि एससीएम गतिविधि पूरी स्क्रीन को भर नहीं पाती है, तो इसे शीर्ष पर संरेखित किया जाता है और क्षैतिज रूप से केन्द्रित किया जाता है। गतिविधि सीमाओं की गणना AppWindowToken#calculateCompatBoundsTransformation() द्वारा की जाती है।

जब कोई SCM गतिविधि अपने कंटेनर से भिन्न स्क्रीन कॉन्फ़िगरेशन का उपयोग करती है (उदाहरण के लिए, डिस्प्ले का आकार बदल दिया जाता है, या गतिविधि को किसी अन्य डिस्प्ले में ले जाया जाता है), ActivityRecord#inSizeCompatMode() सत्य है और SizeCompatModeActivityController (सिस्टम UI में) प्रक्रिया दिखाने के लिए कॉलबैक प्राप्त करता है पुनरारंभ करें बटन.

प्रदर्शन आकार और पहलू अनुपात

एंड्रॉइड 10 लंबी और पतली स्क्रीन के उच्च अनुपात से लेकर 1:1 अनुपात तक नए पहलू अनुपात के लिए समर्थन प्रदान करता है। ऐप्स ApplicationInfo#maxAspectRatio और स्क्रीन के ApplicationInfo#minAspectRatio परिभाषित कर सकते हैं जिन्हें वे संभालने में सक्षम हैं।

एंड्रॉइड 10 में ऐप अनुपात

चित्र 1. एंड्रॉइड 10 में समर्थित उदाहरण ऐप अनुपात

डिवाइस कार्यान्वयन में एंड्रॉइड 9 द्वारा आवश्यक आकार और रिज़ॉल्यूशन से छोटे और कम (न्यूनतम 2.5 इंच चौड़ाई या ऊंचाई, सबसे smallestScreenWidth के लिए न्यूनतम 320 डीपी) के साथ द्वितीयक डिस्प्ले हो सकते हैं, लेकिन केवल ऐसी गतिविधियां जो इन छोटे डिस्प्ले का समर्थन करने का विकल्प चुनती हैं। वहां रखा गया.

ऐप्स न्यूनतम समर्थित आकार की घोषणा करके विकल्प चुन सकते हैं जो लक्ष्य प्रदर्शन आकार के बराबर ओई से छोटा है। ऐसा करने के लिए AndroidManifest में android:minHeight और android:minWidth गतिविधि लेआउट विशेषताओं का उपयोग करें।

नीतियां प्रदर्शित करें

एंड्रॉइड 10 कुछ डिस्प्ले नीतियों को PhoneWindowManager में डिफ़ॉल्ट WindowManagerPolicy कार्यान्वयन से अलग करता है और प्रति-डिस्प्ले कक्षाओं में स्थानांतरित करता है, जैसे:

  • स्थिति और रोटेशन प्रदर्शित करें
  • कुछ कुंजियाँ और गति घटना ट्रैकिंग
  • सिस्टम यूआई और सजावट विंडो

एंड्रॉइड 9 (और उससे नीचे) में, PhoneWindowManager क्लास ने डिस्प्ले नीतियों, स्थिति और सेटिंग्स, रोटेशन, सजावट विंडो फ्रेम ट्रैकिंग और बहुत कुछ को संभाला। एंड्रॉइड 10 रोटेशन ट्रैकिंग को छोड़कर, इसमें से अधिकांश को DisplayPolicy क्लास में ले जाता है, जिसे DisplayRotation में स्थानांतरित कर दिया गया है।

विंडो सेटिंग्स प्रदर्शित करें

एंड्रॉइड 10 में, कॉन्फ़िगर करने योग्य प्रति-डिस्प्ले विंडोिंग सेटिंग को इसमें शामिल करने के लिए विस्तारित किया गया है:

  • डिफ़ॉल्ट डिस्प्ले विंडोिंग मोड
  • ओवरस्कैन मान
  • उपयोगकर्ता रोटेशन और रोटेशन मोड
  • जबरन आकार, घनत्व और स्केलिंग मोड
  • सामग्री हटाने का मोड (जब डिस्प्ले हटा दिया जाता है)
  • सिस्टम सजावट और IME के ​​लिए समर्थन

DisplayWindowSettings क्लास में इन विकल्पों के लिए सेटिंग्स शामिल हैं। हर बार सेटिंग बदलने पर वे display_settings.xml में /data विभाजन में डिस्क पर बने रहते हैं। विवरण के लिए, DisplayWindowSettings.AtomicFileStorage और DisplayWindowSettings#writeSettings() देखें। डिवाइस निर्माता अपने डिवाइस कॉन्फ़िगरेशन के लिए display_settings.xml में डिफ़ॉल्ट मान प्रदान कर सकते हैं। हालाँकि, क्योंकि फ़ाइल /data में संग्रहीत है, वाइप द्वारा मिटाए जाने पर फ़ाइल को पुनर्स्थापित करने के लिए अतिरिक्त तर्क की आवश्यकता हो सकती है।

डिफ़ॉल्ट रूप से, एंड्रॉइड 10 सेटिंग्स को जारी रखते समय डिस्प्ले के पहचानकर्ता के रूप में DisplayInfo#uniqueId का उपयोग करता है। सभी डिस्प्ले के लिए uniqueId पॉप्युलेट किया जाना चाहिए। इसके अलावा, यह भौतिक और नेटवर्क डिस्प्ले के लिए स्थिर है। पहचानकर्ता के रूप में भौतिक डिस्प्ले के पोर्ट का उपयोग करना भी संभव है, जिसे DisplayWindowSettings#mIdentifier में सेट किया जा सकता है। प्रत्येक लिखने पर, सभी सेटिंग्स लिखी जाती हैं इसलिए स्टोरेज में डिस्प्ले प्रविष्टि के लिए उपयोग की जाने वाली कुंजी को अपडेट करना सुरक्षित है। विवरण के लिए, स्टेटिक डिस्प्ले आइडेंटिफ़ायर देखें।

ऐतिहासिक कारणों से सेटिंग्स /data निर्देशिका में बनी रहती हैं। मूल रूप से, उनका उपयोग उपयोगकर्ता द्वारा निर्धारित सेटिंग्स, जैसे डिस्प्ले रोटेशन, को जारी रखने के लिए किया जाता था।

स्थिर प्रदर्शन पहचानकर्ता

एंड्रॉइड 9 (और उससे नीचे) ने फ्रेमवर्क में डिस्प्ले के लिए स्थिर पहचानकर्ता प्रदान नहीं किए। जब सिस्टम में एक डिस्प्ले जोड़ा गया था, तो स्टेटिक काउंटर को बढ़ाकर उस डिस्प्ले के लिए Display#mDisplayId या DisplayInfo#displayId जेनरेट किया गया था। यदि सिस्टम एक ही डिस्प्ले जोड़ता और हटाता है, तो एक अलग आईडी परिणामित होती है।

यदि किसी डिवाइस में बूट से कई डिस्प्ले उपलब्ध हैं, तो समय के आधार पर डिस्प्ले को अलग-अलग पहचानकर्ता दिए जा सकते हैं। जबकि एंड्रॉइड 9 (और पहले) में DisplayInfo#uniqueId शामिल था, इसमें डिस्प्ले के बीच अंतर करने के लिए पर्याप्त जानकारी नहीं थी क्योंकि अंतर्निहित और बाहरी डिस्प्ले का प्रतिनिधित्व करने के लिए भौतिक डिस्प्ले को local:0 या local:1 के रूप में पहचाना गया था।

एंड्रॉइड 10 एक स्थिर पहचानकर्ता जोड़ने और स्थानीय, नेटवर्क और वर्चुअल डिस्प्ले के बीच अंतर करने के लिए DisplayInfo#uniqueId बदलता है।

डिस्प्ले प्रकार प्रारूप
स्थानीय
local:<stable-id>
नेटवर्क
network:<mac-address>
आभासी
virtual:<package-name-and-name>

uniqueId के अपडेट के अलावा, DisplayInfo.address में DisplayAddress शामिल है, एक डिस्प्ले पहचानकर्ता जो रिबूट के दौरान स्थिर होता है। एंड्रॉइड 10 में, DisplayAddress भौतिक और नेटवर्क डिस्प्ले का समर्थन करता है। DisplayAddress.Physical में एक स्थिर डिस्प्ले आईडी होती है ( uniqueId के समान) और DisplayAddress#fromPhysicalDisplayId() के साथ बनाया जा सकता है।

एंड्रॉइड 10 पोर्ट जानकारी प्राप्त करने के लिए एक सुविधाजनक तरीका भी प्रदान करता है ( Physical#getPort() )। इस पद्धति का उपयोग फ्रेमवर्क में डिस्प्ले को स्थिर रूप से पहचानने के लिए किया जा सकता है। उदाहरण के लिए, इसका उपयोग DisplayWindowSettings में किया जाता है)। DisplayAddress.Network में मैक एड्रेस होता है और DisplayAddress#fromMacAddress() के साथ बनाया जा सकता है।

ये परिवर्धन डिवाइस निर्माताओं को स्थिर मल्टी-डिस्प्ले सेट-अप में डिस्प्ले की पहचान करने और भौतिक डिस्प्ले के लिए पोर्ट जैसे स्थिर डिस्प्ले पहचानकर्ताओं का उपयोग करके विभिन्न सिस्टम सेटिंग्स और सुविधाओं को कॉन्फ़िगर करने की अनुमति देते हैं। ये विधियाँ छिपी हुई हैं और इनका उपयोग केवल system_server के भीतर करने के लिए किया गया है।

HWC डिस्प्ले आईडी (जो अपारदर्शी हो सकती है और हमेशा स्थिर नहीं हो सकती) को देखते हुए, यह विधि (प्लेटफ़ॉर्म-विशिष्ट) 8-बिट पोर्ट नंबर लौटाती है जो डिस्प्ले आउटपुट के लिए भौतिक कनेक्टर की पहचान करती है, साथ ही डिस्प्ले के EDID ब्लॉब की भी पहचान करती है। सरफेसफ्लिंगर फ्रेमवर्क के संपर्क में आने वाली स्थिर 64-बिट डिस्प्ले आईडी उत्पन्न करने के लिए ईडीआईडी ​​से निर्माता या मॉडल की जानकारी निकालता है। यदि यह विधि समर्थित नहीं है या त्रुटिपूर्ण है, तो SurfaceFlinger पुराने एमडी मोड पर वापस आ जाता है, जहां DisplayInfo#address शून्य है और DisplayInfo#uniqueId हार्ड-कोडित है, जैसा कि ऊपर बताया गया है।

यह सत्यापित करने के लिए कि यह सुविधा समर्थित है, चलाएँ:

$ dumpsys SurfaceFlinger --display-id
# Example output.
Display 21691504607621632 (HWC display 0): port=0 pnpId=SHP displayName="LQ123P1JX32"
Display 9834494747159041 (HWC display 2): port=1 pnpId=HWP displayName="HP Z24i"
Display 1886279400700944 (HWC display 1): port=2 pnpId=AUS displayName="ASUS MB16AP"

दो से अधिक डिस्प्ले का उपयोग करें

एंड्रॉइड 9 (और उससे पहले) में, सरफेसफ्लिंगर और DisplayManagerService हार्ड-कोडेड आईडी 0 और 1 के साथ अधिकतम दो भौतिक डिस्प्ले के अस्तित्व को मान लिया।

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

SurfaceControl#getPhysicalDisplayToken #getPhysicalDisplayIds से या DisplayEventReceiver हॉटप्लग इवेंट से 64-बिट डिस्प्ले आईडी प्राप्त करने के बाद फ्रेमवर्क SurfaceControl#getPhysicalDisplayIds getPhysicalDisplayToken के माध्यम से भौतिक डिस्प्ले के लिए IBinder टोकन को देख सकता है।

एंड्रॉइड 10 (और उससे नीचे) में, प्राथमिक आंतरिक डिस्प्ले TYPE_INTERNAL है और कनेक्शन प्रकार की परवाह किए बिना सभी माध्यमिक डिस्प्ले को TYPE_EXTERNAL के रूप में चिह्नित किया गया है। इसलिए, अतिरिक्त आंतरिक डिस्प्ले को बाहरी माना जाता है। वर्कअराउंड के रूप में, यदि HWC ज्ञात है और पोर्ट आवंटन तर्क पूर्वानुमानित है, तो डिवाइस-विशिष्ट कोड DisplayAddress.Physical#getPort के बारे में धारणा बना सकता है।

एंड्रॉइड 11 (और उच्चतर) में यह सीमा हटा दी गई है।

  • एंड्रॉइड 11 में, बूट के दौरान रिपोर्ट किया गया पहला डिस्प्ले प्राथमिक डिस्प्ले है। कनेक्शन प्रकार (आंतरिक बनाम बाहरी) अप्रासंगिक है। हालाँकि, यह सच है कि प्राथमिक डिस्प्ले को डिस्कनेक्ट नहीं किया जा सकता है और व्यवहार में यह एक आंतरिक डिस्प्ले होना चाहिए। ध्यान दें कि कुछ फोल्डेबल फोन में कई आंतरिक डिस्प्ले होते हैं।
  • सेकेंडरी डिस्प्ले को उनके कनेक्शन प्रकार के आधार पर सही ढंग से Display.TYPE_INTERNAL या Display.TYPE_EXTERNAL (पहले क्रमश: Display.TYPE_BUILT_IN और Display.TYPE_HDMI के रूप में जाना जाता था) के रूप में वर्गीकृत किया गया है।

कार्यान्वयन

एंड्रॉइड 9 और उससे पहले के संस्करण में, डिस्प्ले को 32-बिट आईडी द्वारा पहचाना जाता है, जहां 0 आंतरिक डिस्प्ले है, 1 बाहरी डिस्प्ले है, [2, INT32_MAX] HWC वर्चुअल डिस्प्ले हैं, और -1 एक अमान्य डिस्प्ले या गैर-HWC का प्रतिनिधित्व करता है आभासी प्रदर्शन.

एंड्रॉइड 10 से शुरू होकर, डिस्प्ले को स्थिर और लगातार आईडी दी जाती है, जो सरफेसफ्लिंगर और DisplayManagerService दो से अधिक डिस्प्ले को ट्रैक करने और पहले देखे गए डिस्प्ले को पहचानने की अनुमति देता है। यदि HWC IComposerClient.getDisplayIdentificationData का समर्थन करता है और डिस्प्ले पहचान डेटा प्रदान करता है, तो SurfaceFlinger EDID संरचना को पार्स करता है और भौतिक और HWC वर्चुअल डिस्प्ले के लिए स्थिर 64-बिट डिस्प्ले आईडी आवंटित करता है। आईडी को एक विकल्प प्रकार का उपयोग करके व्यक्त किया जाता है, जहां शून्य मान एक अमान्य डिस्प्ले या गैर-एचडब्ल्यूसी वर्चुअल डिस्प्ले का प्रतिनिधित्व करता है। HWC समर्थन के बिना, SurfaceFlinger अधिकतम दो भौतिक डिस्प्ले के साथ पुराने व्यवहार पर वापस आ जाता है।

प्रति-प्रदर्शन फोकस

एक ही समय में अलग-अलग डिस्प्ले को लक्षित करने वाले कई इनपुट स्रोतों का समर्थन करने के लिए, एंड्रॉइड 10 को अधिकतम एक प्रति-डिस्प्ले, एकाधिक केंद्रित विंडो का समर्थन करने के लिए कॉन्फ़िगर किया जा सकता है। यह केवल विशेष प्रकार के उपकरणों के लिए है, जब कई उपयोगकर्ता एक ही समय में एक ही डिवाइस के साथ इंटरैक्ट करते हैं और विभिन्न इनपुट विधियों या उपकरणों का उपयोग करते हैं, जैसे कि एंड्रॉइड ऑटोमोटिव।

यह दृढ़ता से अनुशंसा की जाती है कि इस सुविधा को नियमित उपकरणों के लिए सक्षम किया जाए, जिसमें मल्टी-स्क्रीन डिवाइस या डेस्कटॉप जैसे अनुभवों के लिए उपयोग किए जाने वाले डिवाइस शामिल हैं। यह मुख्य रूप से एक सुरक्षा चिंता के कारण है जिससे उपयोगकर्ताओं को आश्चर्य हो सकता है कि किस विंडो में इनपुट फोकस है।

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

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

प्रति-डिस्प्ले फोकस सेट करने के लिए com.android.internal.R.bool.config_perDisplayFocusEnabled का उपयोग करें।

अनुकूलता

समस्या: एंड्रॉइड 9 और उससे पहले के संस्करण में, सिस्टम में एक समय में अधिकतम एक विंडो पर फोकस होता है।

समाधान: दुर्लभ मामले में जब एक ही प्रक्रिया से दो विंडो पर ध्यान केंद्रित किया जाएगा, तो सिस्टम केवल उस विंडो पर फोकस प्रदान करता है जो Z-क्रम में उच्चतर है। यह प्रतिबंध उन ऐप्स के लिए हटा दिया गया है जो एंड्रॉइड 10 को लक्षित करते हैं, जिस बिंदु पर यह उम्मीद की जाती है कि वे एक साथ कई विंडोज़ पर ध्यान केंद्रित करने का समर्थन कर सकते हैं।

कार्यान्वयन

WindowManagerService#mPerDisplayFocusEnabled इस सुविधा की उपलब्धता को नियंत्रित करता है। ActivityManager में, अब एक वेरिएबल में वैश्विक ट्रैकिंग के बजाय ActivityDisplay#getFocusedStack() उपयोग किया जाता है। ActivityDisplay#getFocusedStack() मान को कैश करने के बजाय Z-ऑर्डर के आधार पर फोकस निर्धारित करता है। ऐसा इसलिए है कि केवल एक स्रोत, विंडोमैनेजर, को गतिविधियों के Z-क्रम को ट्रैक करने की आवश्यकता है।

ActivityStackSupervisor#getTopDisplayFocusedStack() उन मामलों के लिए एक समान दृष्टिकोण अपनाता है जब सिस्टम में सबसे शीर्ष केंद्रित स्टैक की पहचान की जानी चाहिए। पहले योग्य स्टैक की खोज करते हुए, स्टैक को ऊपर से नीचे तक घुमाया जाता है।

InputDispatcher अब कई केंद्रित विंडो (प्रति डिस्प्ले एक) हो सकती हैं। यदि कोई इनपुट इवेंट डिस्प्ले-विशिष्ट है, तो इसे संबंधित डिस्प्ले में केंद्रित विंडो पर भेज दिया जाता है। अन्यथा, इसे फोकस्ड डिस्प्ले में फोकस्ड विंडो पर भेज दिया जाता है, जो कि वह डिस्प्ले है जिसके साथ उपयोगकर्ता ने हाल ही में इंटरैक्ट किया है।

InputDispatcher::mFocusedWindowHandlesByDisplay और InputDispatcher::setFocusedDisplay() देखें। फोकस्ड ऐप्स को InputManagerService में NativeInputManager::setFocusedApplication() के माध्यम से अलग से अपडेट किया जाता है।

WindowManager में, फोकस्ड विंडो को भी अलग से ट्रैक किया जाता है। DisplayContent#mCurrentFocus और DisplayContent#mFocusedApp और संबंधित उपयोग देखें। संबंधित फोकस ट्रैकिंग और अपडेटिंग विधियों को WindowManagerService से DisplayContent में स्थानांतरित कर दिया गया है।