इन प्रदर्शन-विशिष्ट क्षेत्रों में किए गए अपडेट नीचे दिए गए हैं:
सिस्टम सजावट
एंड्रॉइड 10 कुछ सिस्टम सजावट, जैसे वॉलपेपर, नेविगेशन बार और लॉन्चर दिखाने के लिए सेकेंडरी डिस्प्ले को कॉन्फ़िगर करने के लिए समर्थन जोड़ता है। डिफ़ॉल्ट रूप से, प्राथमिक डिस्प्ले सभी सिस्टम सजावट दिखाता है, और द्वितीयक डिस्प्ले वैकल्पिक रूप से सक्षम दिखाता है। इनपुट मेथड एडिटर (IME) के लिए समर्थन को अन्य सिस्टम सजावट से अलग सेट किया जा सकता है।
किसी विशिष्ट डिस्प्ले पर सिस्टम सजावट के लिए समर्थन जोड़ने या /data/system/display_settings.xml
में एक डिफ़ॉल्ट मान प्रदान करने के लिए DisplayWindowSettings#setShouldShowSystemDecorsLocked()
का उपयोग करें। उदाहरण के लिए, डिस्प्ले विंडो सेटिंग्स देखें।
कार्यान्वयन
DisplayWindowSettings#setShouldShowSystemDecorsLocked()
परीक्षण के लिए WindowManager#setShouldShowSystemDecors()
में भी प्रदर्शित किया गया है। सिस्टम सजावट को सक्षम करने के इरादे से इस पद्धति को ट्रिगर करने से उन सजावटी खिड़कियों को नहीं जोड़ा जाता है जो पहले गायब थीं, या यदि वे पहले से मौजूद थीं तो उन्हें हटा नहीं दिया जाता है। ज्यादातर मामलों में, सिस्टम डेकोरेशन सपोर्ट में बदलाव डिवाइस रीबूट के बाद ही पूर्ण रूप से प्रभावी होता है।
विंडोमैनेजर कोड बेस में सिस्टम डेकोरेशन के समर्थन की जांच आमतौर पर DisplayContent#supportsSystemDecorations()
से होती है, जबकि बाहरी सेवाओं (जैसे सिस्टम यूआई यह जांचने के लिए कि नेविगेशन बार दिखाया जाना चाहिए या नहीं) के लिए WindowManager#shouldShowSystemDecors()
उपयोग किया जाता है। यह समझने के लिए कि इस सेटिंग द्वारा क्या नियंत्रित किया जाता है, इन विधियों के कॉल पॉइंट का पता लगाएं।
सिस्टम यूआई सजावट विंडोज़
एंड्रॉइड 10 केवल नेविगेशन बार के लिए सिस्टम डेकोर विंडो समर्थन जोड़ता है, क्योंकि नेविगेशन बार गतिविधियों और ऐप्स के बीच नेविगेट करने के लिए आवश्यक है। डिफ़ॉल्ट रूप से, नेविगेशन बार बैक और होम अफोर्डेंस दिखाता है। इसे केवल तभी शामिल किया जाता है जब लक्ष्य डिस्प्ले सिस्टम सजावट का समर्थन करता है ( DisplayWindowSettings
देखें)।
स्टेटस बार एक अधिक जटिल सिस्टम विंडो है, क्योंकि इसमें नोटिफिकेशन शेड, क्विक सेटिंग्स और लॉक स्क्रीन भी शामिल है। एंड्रॉइड 10 में, स्टेटस बार सेकेंडरी डिस्प्ले पर समर्थित नहीं है। इसलिए, सूचनाएं, सेटिंग्स और पूर्ण कीगार्ड केवल प्राथमिक डिस्प्ले पर उपलब्ध हैं।
अवलोकन/हालिया सिस्टम विंडो द्वितीयक स्क्रीन पर समर्थित नहीं है। एंड्रॉइड 10 में, एओएसपी डिफ़ॉल्ट डिस्प्ले पर केवल हालिया प्रदर्शित करता है और इसमें सभी डिस्प्ले की गतिविधियां शामिल होती हैं। जब हाल ही से लॉन्च किया जाता है, तो एक गतिविधि जो द्वितीयक डिस्प्ले पर थी, उसे डिफ़ॉल्ट रूप से उस डिस्प्ले पर सामने लाया जाता है। इस दृष्टिकोण में कुछ ज्ञात समस्याएं हैं, जैसे अन्य स्क्रीन पर ऐप्स दिखाई देने पर तुरंत अपडेट न होना।
कार्यान्वयन
अतिरिक्त सिस्टम यूआई सुविधाओं को लागू करने के लिए, डिवाइस निर्माताओं को एकल सिस्टम यूआई घटक का उपयोग करना चाहिए जो डिस्प्ले को जोड़ने/हटाने के लिए सुनता है और उचित सामग्री प्रस्तुत करता है।
मल्टी-डिस्प्ले (एमडी) का समर्थन करने वाले सिस्टम यूआई घटक को निम्नलिखित मामलों को संभालना चाहिए:
- स्टार्टअप पर मल्टीपल डिस्प्ले इनिशियलाइज़ेशन
- रनटाइम पर डिस्प्ले जोड़ा गया
- रनटाइम पर डिस्प्ले हटा दिया गया
जब सिस्टम यूआई विंडोमैनेजर से पहले एक डिस्प्ले के जुड़ने का पता लगाता है, तो यह एक रेस की स्थिति बनाता है। जब डिस्प्लेमैनेजर .DisplayListener
इवेंट की सदस्यता लेने के बजाय एक डिस्प्ले जोड़ा जाता है, तो विंडोमैनेजर से सिस्टम यूआई में एक कस्टम कॉलबैक लागू करके इससे बचा जा सकता है। संदर्भ कार्यान्वयन के लिए, नेविगेशन बार समर्थन के लिए CommandQueue.Callbacks#onDisplayReady
और वॉलपेपर के लिए WallpaperManagerInternal#onDisplayReady
देखें।
इसके अलावा, Android 10 ये अपडेट प्रदान करता है:
-
NavigationBarController
क्लास नेविगेशन बार के लिए विशिष्ट सभी कार्यक्षमता को नियंत्रित करता है। - अनुकूलित नेविगेशन बार देखने के लिए,
CarStatusBar
देखें। -
TYPE_NAVIGATION_BAR
अब एक ही उदाहरण तक सीमित नहीं है और इसका उपयोग प्रति डिस्प्ले किया जा सकता है। -
IWindowManager#hasNavigationBar()
केवल सिस्टम UI के लिएdisplayId
पैरामीटर को शामिल करने के लिए अद्यतन किया गया है।
लांचर
एंड्रॉइड 10 में, सिस्टम सजावट का समर्थन करने के लिए कॉन्फ़िगर किए गए प्रत्येक डिस्प्ले में डिफ़ॉल्ट रूप से WindowConfiguration#ACTIVITY_TYPE_HOME
प्रकार के साथ लॉन्चर गतिविधियों के लिए एक समर्पित होम स्टैक होता है। प्रत्येक डिस्प्ले लॉन्चर गतिविधि के एक अलग उदाहरण का उपयोग करता है।
चित्र 1. platform/development/samples/MultiDisplay
के लिए मल्टी-डिस्प्ले लॉन्चर उदाहरण
अधिकांश मौजूदा लॉन्चर कई उदाहरणों का समर्थन नहीं करते हैं और बड़े स्क्रीन आकार के लिए अनुकूलित नहीं हैं। साथ ही, सेकेंडरी/एक्सटर्नल डिस्प्ले पर अक्सर एक अलग तरह के अनुभव की उम्मीद की जाती है। सेकेंडरी स्क्रीन के लिए एक समर्पित गतिविधि प्रदान करने के लिए, एंड्रॉइड 10 इंटेंट फिल्टर में SECONDARY_HOME
श्रेणी पेश करता है। इस गतिविधि के उदाहरणों का उपयोग उन सभी डिस्प्ले पर किया जाता है जो सिस्टम सजावट का समर्थन करते हैं, प्रति डिस्प्ले एक।
<activity> ... <intent-filter> <category android:name="android.intent.category.SECONDARY_HOME" /> ... </intent-filter> </activity>
गतिविधि में एक लॉन्च मोड होना चाहिए जो कई उदाहरणों को नहीं रोकता है और विभिन्न स्क्रीन आकारों के अनुकूल होने की उम्मीद है। लॉन्च मोड singleInstance
या singleTask
नहीं हो सकता।
कार्यान्वयन
एंड्रॉइड 10 में, RootActivityContainer#startHomeOnDisplay()
होम स्क्रीन लॉन्च होने वाले डिस्प्ले के आधार पर स्वचालित रूप से वांछित घटक और इरादे का चयन करता है। RootActivityContainer#resolveSecondaryHomeActivity()
में वर्तमान में चयनित लॉन्चर के आधार पर लॉन्चर गतिविधि घटक को देखने का तर्क शामिल है और यदि आवश्यक हो, तो सिस्टम डिफ़ॉल्ट का उपयोग कर सकता है ( ActivityTaskManagerService#getSecondaryHomeIntent()
देखें)।
सुरक्षा प्रतिबंध
सेकेंडरी डिस्प्ले पर गतिविधियों पर लागू होने वाले प्रतिबंधों के अलावा, किसी दुर्भावनापूर्ण ऐप द्वारा सक्षम सिस्टम सजावट के साथ वर्चुअल डिस्प्ले बनाने और सतह से उपयोगकर्ता-संवेदनशील जानकारी पढ़ने की संभावना से बचने के लिए, लॉन्चर केवल सिस्टम के स्वामित्व वाले वर्चुअल डिस्प्ले पर दिखाई देता है। लॉन्चर गैर-सिस्टम वर्चुअल डिस्प्ले पर सामग्री प्रदर्शित नहीं करता है।
वॉलपेपर
एंड्रॉइड 10 (और उच्चतर) में, वॉलपेपर सेकेंडरी डिस्प्ले पर समर्थित हैं:
चित्र 2. आंतरिक (ऊपर) और बाहरी डिस्प्ले (नीचे) पर लाइव वॉलपेपर
डेवलपर्स WallpaperInfo
XML परिभाषा में android:supportsMultipleDisplays="true"
प्रदान करके वॉलपेपर सुविधा के लिए समर्थन की घोषणा कर सकते हैं। वॉलपेपर डेवलपर्स से यह भी अपेक्षा की जाती है कि WallpaperService.Engine#getDisplayContext()
में डिस्प्ले संदर्भ का उपयोग करके संपत्ति लोड करें।
फ्रेमवर्क प्रति डिस्प्ले एक WallpaperService.Engine
इंस्टेंस बनाता है, इसलिए प्रत्येक इंजन की अपनी सतह और डिस्प्ले संदर्भ होता है। डेवलपर को यह सुनिश्चित करना होगा कि प्रत्येक इंजन वीएसवाईएनसी का सम्मान करते हुए, अलग-अलग फ्रेम दर पर स्वतंत्र रूप से आकर्षित हो सके।
अलग-अलग स्क्रीन के लिए वॉलपेपर चुनें
एंड्रॉइड 10 अलग-अलग स्क्रीन के लिए वॉलपेपर चुनने के लिए प्रत्यक्ष प्लेटफ़ॉर्म समर्थन प्रदान नहीं करता है। इसे पूरा करने के लिए, प्रति डिस्प्ले वॉलपेपर सेटिंग्स को जारी रखने के लिए एक स्थिर डिस्प्ले पहचानकर्ता की आवश्यकता होती है। Display#getDisplayId()
गतिशील है, इसलिए इसकी कोई गारंटी नहीं है कि रीबूट के बाद भौतिक डिस्प्ले में वही आईडी होगी।
हालाँकि, एंड्रॉइड 10 ने DisplayInfo.mAddress
जोड़ा, जिसमें भौतिक डिस्प्ले के लिए स्थिर पहचानकर्ता शामिल हैं और भविष्य में पूर्ण कार्यान्वयन के लिए इसका उपयोग किया जा सकता है। दुर्भाग्य से, एंड्रॉइड 10 के लिए तर्क लागू करने में बहुत देर हो चुकी है। सुझाया गया समाधान:
- वॉलपेपर सेट करने के लिए
WallpaperManager
एपीआई का उपयोग करें। -
WallpaperManager
एकContext
ऑब्जेक्ट से प्राप्त किया जाता है, और प्रत्येकContext
ऑब्जेक्ट में संबंधित डिस्प्ले (Context#getDisplay()/getDisplayId()
) के बारे में जानकारी होती है। इसलिए, आप नए तरीकों को जोड़े बिनाWallpaperManager
इंस्टेंस सेdisplayId
प्राप्त कर सकते हैं। - फ़्रेमवर्क पक्ष पर, किसी
Context
ऑब्जेक्ट से प्राप्तdisplayId
उपयोग करें और इसे एक स्थिर पहचानकर्ता (जैसे भौतिक डिस्प्ले का पोर्ट) पर मैप करें। चुने गए वॉलपेपर को बनाए रखने के लिए स्थिर पहचानकर्ता का उपयोग करें।
यह समाधान वॉलपेपर चुनने वालों के लिए मौजूदा कार्यान्वयन का उपयोग करता है। यदि यह एक विशिष्ट डिस्प्ले पर खोला गया था और सही संदर्भ का उपयोग करता है, तो जब यह वॉलपेपर सेट करने के लिए कॉल करता है, तो सिस्टम स्वचालित रूप से डिस्प्ले की पहचान कर सकता है।
यदि वर्तमान डिस्प्ले के अलावा किसी अन्य डिस्प्ले के लिए वॉलपेपर सेट करने की आवश्यकता है, तो लक्ष्य डिस्प्ले के लिए एक नया Context
ऑब्जेक्ट बनाएं ( Context#createDisplayContext
) और उस डिस्प्ले से WallpaperManager
इंस्टेंस प्राप्त करें।
सुरक्षा प्रतिबंध
सिस्टम उन वर्चुअल डिस्प्ले पर वॉलपेपर नहीं दिखाएगा जो उसके पास नहीं हैं। यह एक सुरक्षा चिंता के कारण है कि एक दुर्भावनापूर्ण ऐप सक्षम सिस्टम डेकोरेशन समर्थन के साथ एक वर्चुअल डिस्प्ले बना सकता है और सतह से उपयोगकर्ता-संवेदनशील जानकारी (जैसे कि एक व्यक्तिगत फोटो) पढ़ सकता है।
कार्यान्वयन
एंड्रॉइड 10 में, IWallpaperConnection#attachEngine()
और IWallpaperService#attach()
इंटरफेस प्रति-डिस्प्ले कनेक्शन बनाने के लिए displayId
पैरामीटर स्वीकार करते हैं। WallpaperManagerService.DisplayConnector
एक प्रति-डिस्प्ले वॉलपेपर इंजन और कनेक्शन को समाहित करता है। विंडोमैनेजर में, सभी डिस्प्ले के लिए एकल WallpaperController
के बजाय निर्माण के समय प्रत्येक DisplayContent
ऑब्जेक्ट के लिए वॉलपेपर नियंत्रक बनाए जाते हैं।
कुछ सार्वजनिक WallpaperManager
विधि कार्यान्वयन (जैसे कि WallpaperManager#getDesiredMinimumWidth()
) को गणना करने और संबंधित डिस्प्ले के लिए जानकारी प्रदान करने के लिए अद्यतन किया गया था। WallpaperInfo#supportsMultipleDisplays()
और एक संबंधित संसाधन विशेषता जोड़ी गई थी, ताकि ऐप डेवलपर्स रिपोर्ट कर सकें कि कौन से वॉलपेपर एकाधिक स्क्रीन के लिए तैयार हैं।
यदि डिफ़ॉल्ट डिस्प्ले पर दिखाई गई वॉलपेपर सेवा एकाधिक डिस्प्ले का समर्थन नहीं करती है, तो सिस्टम द्वितीयक डिस्प्ले पर डिफ़ॉल्ट वॉलपेपर दिखाता है।
चित्र 3. द्वितीयक डिस्प्ले के लिए वॉलपेपर फ़ॉलबैक तर्क