डिसप्ले सपोर्ट

डिसप्ले से जुड़े इन खास इलाकों में किए गए अपडेट नीचे दिए गए हैं:

• गतिविधियों और डिसप्ले का साइज़ बदलना
• डिसप्ले साइज़ और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)
• डिसप्ले से जुड़ी नीतियां
• डिसप्ले विंडो की सेटिंग
• स्टैटिक डिसप्ले आइडेंटिफ़ायर
• दो से ज़्यादा डिसप्ले का इस्तेमाल करना
• हर डिसप्ले पर फ़ोकस

गतिविधियों और डिसप्ले का साइज़ बदलें

यह बताने के लिए कि किसी ऐप्लिकेशन में मल्टी-विंडो मोड या साइज़ बदलने की सुविधा शायद काम न करे, गतिविधियों के लिए resizeableActivity=false एट्रिब्यूट का इस्तेमाल किया जाता है. कॉमन गतिविधियों का साइज़ बदलने पर, ऐप्लिकेशन में आने वाली समस्याओं में ये शामिल हैं:

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

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

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

• प्रोसेस पर वही कॉन्फ़िगरेशन लागू होता है जिसमें सभी गतिविधियां शामिल होती हैं और नॉन-ऐक्टिविटी कॉम्पोनेंट शामिल होते हैं.
• लागू किया गया कॉन्फ़िगरेशन, ऐप्लिकेशन के साथ काम करने के लिए CDD की ज़रूरी शर्तों को पूरा करता है दिखाता है.

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

डिफ़ॉल्ट रूप से लागू होने पर, यह नीति लागू होगी:

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

• इसके अनुप्रयोग के माध्यम से स्थायी ओरिएंटेशन बनाया जाता है android:screenOrientation
• एपीआई लेवल को टारगेट करने पर, ऐप्लिकेशन का डिफ़ॉल्ट तौर पर सबसे ज़्यादा या कम से कम आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) तय होता है इसके अलावा, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के बारे में साफ़ तौर पर बताया गया हो

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

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

जब resizeableActivity सेट न हो या इस पर सेट हो true), ऐप्लिकेशन का साइज़ बदलने की सुविधा पूरी तरह से काम करती है.

लागू करना

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

अगर एससीएम गतिविधि पूरी स्क्रीन को पूरा नहीं कर पा रही है, तो यह टॉप अलाइन है और हॉरिज़ॉन्टल तौर पर सेंटर करें. गतिविधियों की सीमाओं का हिसाब इस तरह से लगाया जाता है कि लोग AppWindowToken#calculateCompatBoundsTransformation().

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

डिसप्ले साइज़ और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

Android 10, नए आसपेक्ट रेशियो के साथ काम करता है आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) 1:1 के अनुपात में होता है. ऐप्लिकेशन ApplicationInfo#maxAspectRatio और स्क्रीन के ApplicationInfo#minAspectRatio संभाल नहीं सकता.

पहला डायग्राम. Android में काम करने वाले ऐप्लिकेशन के अनुपात के उदाहरण 10 मिनट

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

ऐप्लिकेशन, तय साइज़ से छोटे साइज़ की जानकारी देकर, ऑप्ट-इन कर सकते हैं या डिसप्ले के टारगेट साइज़ के बराबर हो. android:minHeight का इस्तेमाल करें और इसमें android:minWidth गतिविधि लेआउट एट्रिब्यूट ऐसा करने के लिए AndroidManifest.

डिसप्ले से जुड़ी नीतियां

खास डिसप्ले को अलग करके, Android 10 पर सेट कर दिया जाता है ये नीतियां, डिफ़ॉल्ट रूप से WindowManagerPolicy के लागू होने पर PhoneWindowManager से हर-डिसप्ले क्लास में, जैसे कि:

• डिसप्ले की स्थिति और रोटेशन
• कुछ कुंजियां और मोशन इवेंट ट्रैकिंग
• सिस्टम यूज़र इंटरफ़ेस (यूआई) और डेकोरेशन विंडो

Android 9 और इससे पहले के वर्शन में, PhoneWindowManager क्लास डिसप्ले नीतियां, स्थिति और सेटिंग, घुमाना, सजावट वाली विंडो फ़्रेम ट्रैकिंग वगैरह. Android 10, ऐप्लिकेशन का ज़्यादातर अपडेट DisplayPolicy क्लास को छोड़कर, इसमें रोटेशन ट्रैकिंग शामिल है, जिसमें DisplayRotation में ले जाए गए.

डिसप्ले विंडो की सेटिंग

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

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

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

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

पुराने डेटा के लिए, सेटिंग /data डायरेक्ट्री में लागू रहती हैं की वजह. शुरुआत में, इनका इस्तेमाल उपयोगकर्ता की सेट की गई सेटिंग को बनाए रखने के लिए किया जाता था. जैसे, डिसप्ले को घुमाना.

स्टैटिक डिसप्ले आइडेंटिफ़ायर

Android 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 शामिल है, डिसप्ले आइडेंटिफ़ायर दिया गया है, जो सभी रीबूट पर स्थिर रहता है. Android में 10, DisplayAddress फ़िज़िकल तौर पर काम करता है और नेटवर्क डिसप्ले. DisplayAddress.Physical में एक स्टेबल है डिसप्ले आईडी (uniqueId के जैसा) और इसे इसकी मदद से बनाया जा सकता है DisplayAddress#fromPhysicalDisplayId().

Android 10, Android 10 पर आसानी से पोर्ट की जानकारी (Physical#getPort()). इस तरीके का इस्तेमाल इसमें किया जा सकता है स्टैटिक तरीके से डिसप्ले की पहचान करने वाला फ़्रेमवर्क. उदाहरण के लिए, इसका इस्तेमाल DisplayWindowSettings). DisplayAddress.Network में MAC पता होता है और इसे इससे बनाया जा सकता है DisplayAddress#fromMacAddress().

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

एक एचडब्ल्यूसी डिसप्ले आईडी दिया जाता है, जो साफ़ नहीं होती और हमेशा स्थिर नहीं होती. तरीका (प्लैटफ़ॉर्म के हिसाब से) 8-बिट पोर्ट नंबर देता है, जो डिसप्ले आउटपुट के लिए फ़िज़िकल कनेक्टर और डिसप्ले के EDID BLOB के लिए. SurfaceFlinger, ईडीआईडी फ़ंक्शन से मैन्युफ़ैक्चरर या मॉडल की जानकारी हासिल करके फ़्रेमवर्क के दिख रहे स्टेबल 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"

दो से ज़्यादा डिसप्ले का इस्तेमाल करना

Android 9 और इससे पहले के वर्शन वाले डिवाइसों के लिए, SurfaceFlinger और DisplayManagerService में हार्ड कोड किए गए आईडी 0 के साथ ज़्यादा से ज़्यादा दो फ़िज़िकल डिसप्ले के होने की संभावना का पता चलता है और 1.

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

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

Android 10 और उससे पहले के वर्शन में, मुख्य इंटरनल डिसप्ले TYPE_INTERNAL और सभी सेकंडरी डिसप्ले को TYPE_EXTERNAL के तौर पर फ़्लैग किया गया है कनेक्शन टाइप पर ध्यान दिए बिना. इसलिए, अतिरिक्त इंटरनल डिसप्ले को बाहरी डिसप्ले माना जाता है. समाधान के तौर पर, डिवाइस के हिसाब से बना कोड अगर एचडब्ल्यूसी और पोर्ट ऐलोकेशन की जानकारी है, तो DisplayAddress.Physical#getPort लॉजिक के बारे में पहले से अनुमान लगाया जा सकता है.

इस पाबंदी को Android 11 और उसके बाद के वर्शन में हटा दिया गया है.

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

लागू करना

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

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

हर डिसप्ले पर फ़ोकस

एक ही समय पर अलग-अलग डिसप्ले को टारगेट करने वाले कई इनपुट सोर्स का इस्तेमाल करना समय, Android 10 को अलग-अलग Android 10 विंडो पर फ़ोकस किया जा सकता है. यह सिर्फ़ खास लोगों के लिए है डिवाइस के प्रकार जब कई उपयोगकर्ता एक ही डिवाइस से एक ही समय पर इंटरैक्ट करते हैं और इनपुट के अलग-अलग तरीकों या डिवाइसों का इस्तेमाल करें, जैसे कि Android ऑटोमोटिव.

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

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

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

com.android.internal.R.bool.config_perDisplayFocusEnabled का इस्तेमाल करें का इस्तेमाल करें.

काम करता है या नहीं

समस्या: Android 9 और उससे पहले के वर्शन में, सिस्टम पर फ़ोकस है.

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

लागू करना

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

ActivityStackSupervisor#getTopDisplayFocusedStack() ने जब सिस्टम में सबसे ज़्यादा फ़ोकस किया गया स्टैक मिलता है, तो उन मामलों में यह तरीका अपनाया जाता है पहचान होनी चाहिए. स्टैक को ऊपर से नीचे घुमाया जाता है. ज़रूरी शर्तें पूरी करने वाला पहला स्टैक.

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

InputDispatcher::mFocusedWindowHandlesByDisplay और InputDispatcher::setFocusedDisplay(). फ़ोकस किए गए ऐप्लिकेशन भी अपडेट कर दिए जाते हैं इसके ज़रिए इनपुट मैनेजर सेवा में अलग से NativeInputManager::setFocusedApplication().

WindowManager में, फ़ोकस की गई विंडो को भी अलग से ट्रैक किया जाता है. DisplayContent#mCurrentFocus और DisplayContent#mFocusedApp और इससे जुड़े दूसरे इस्तेमाल. इस विषय पर फ़ोकस करने वाली बातें ट्रैकिंग और अपडेट करने के तरीके DisplayContent के लिए WindowManagerService.