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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कार्यान्वयन

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

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

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

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

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

Android 10 . में ऐप अनुपात

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

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

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

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

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

  • राज्य और रोटेशन प्रदर्शित करें
  • कुछ कुंजी और गति घटना ट्रैकिंग
  • सिस्टम UI और डेकोरेशन विंडो

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एक एचडब्ल्यूसी डिस्प्ले आईडी (जो अपारदर्शी हो सकती है और हमेशा स्थिर नहीं हो सकती है) को देखते हुए, यह विधि (प्लेटफ़ॉर्म-विशिष्ट) 8-बिट पोर्ट नंबर देता है जो डिस्प्ले आउटपुट के साथ-साथ डिस्प्ले के ईडीआईडी ​​​​ब्लॉब के लिए एक भौतिक कनेक्टर की पहचान करता है। सरफेसफ्लिंगर ईडीआईडी ​​से निर्माता या मॉडल की जानकारी निकालता है ताकि फ्रेमवर्क के सामने स्थिर 64-बिट डिस्प्ले आईडी उत्पन्न हो सके। यदि यह विधि समर्थित नहीं है या त्रुटिपूर्ण है, तो SurfaceFlinger लीगेसी MD मोड पर वापस आ जाता है, जहां 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 (और निचले) में, SurfaceFlinger और DisplayManagerService ने हार्ड-कोडेड आईडी 0 और 1 के साथ अधिकतम दो भौतिक डिस्प्ले के अस्तित्व को ग्रहण किया।

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

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

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

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

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

कार्यान्वयन

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

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

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

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

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

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

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

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

अनुकूलता

समस्या: Android 9 और उससे पहले के वर्शन में, सिस्टम में एक समय में ज़्यादा से ज़्यादा एक विंडो पर फ़ोकस होता है।

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

कार्यान्वयन

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

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

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

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

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