मल्टी-रिज्यूमे

एंड्रॉइड 9 (और उससे पहले) में, ऐप्स को PAUSED स्थिति में दर्ज किया गया था जब:

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

ये स्थितियाँ किसी ऐप को रोकने की मात्रा में भिन्न होती हैं लेकिन ऐप स्तर पर इन्हें अलग नहीं किया जा सकता है।

एंड्रॉइड 10 में, दृश्यमान स्टैक में सभी शीर्ष-फोकस करने योग्य गतिविधियां RESUMED स्थिति में रहती हैं। यह उन ऐप्स के लिए मल्टी-विंडो और एमडी मोड के साथ संगतता में सुधार करता है जो यूआई को रीफ्रेश करने और उपयोगकर्ता के साथ इंटरैक्ट करने से रोकने के लिए onPause() के बजाय onStop() उपयोग करते हैं। इसका मतलब यह है:

• स्प्लिट-स्क्रीन में दोनों गतिविधियाँ फिर से शुरू हो गई हैं।
• फ़्री-फ़ॉर्म विंडोिंग मोड में सभी शीर्ष-दृश्यमान गतिविधियाँ फिर से शुरू हो गई हैं।
• एक ही समय में एकाधिक स्क्रीन पर गतिविधियाँ फिर से शुरू की जा सकती हैं।

चित्र 1. फोल्डेबल डिवाइस पर मल्टी-रेज़्यूमे

चित्र 2. डेस्कटॉप मोड में मल्टी-रेज़्यूमे

गतिविधियाँ PAUSED स्थिति में रह सकती हैं जब उन पर ध्यान केंद्रित नहीं किया जा सकता है या आंशिक रूप से अवरुद्ध किया गया है, जैसे:

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

यह दृष्टिकोण ऐप्स को इंगित करता है कि कोई गतिविधि केवल RESUMED स्थिति में ही उपयोगकर्ता से इनपुट प्राप्त कर सकती है। एंड्रॉइड 10 से पहले, गतिविधियाँ PAUSED स्थिति में भी इनपुट प्राप्त कर सकती थीं (उदाहरण के लिए, एंड्रॉइड 9 चलाने वाले डिवाइस पर स्प्लिट-स्क्रीन में दोनों गतिविधियों को एक साथ छूने का प्रयास करें)।

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

Activity#onTopResumedActivityChanged(boolean onTop)

जब लागू किया जाता है, तो इस कॉलबैक को Activity#onResume() और Activity#onPause() के बीच कॉल किया जाता है। यह कॉलबैक वैकल्पिक है और इसे छोड़ा जा सकता है, इसलिए कोई गतिविधि सिस्टम में शीर्ष पर आए बिना RESUMED PAUSED स्थिति से रुकी हुई स्थिति में जा सकती है। उदाहरण के लिए, मल्टी-विंडो मोड में। क्योंकि यह कॉलबैक वैकल्पिक है, यह गतिविधि जीवनचक्र का हिस्सा नहीं है और इसका उपयोग शायद ही कभी किया जाना चाहिए।

पिछली शीर्ष-फिर से शुरू की गई गतिविधि onTopResumedActivity(false) प्राप्त करती है और अगली शीर्ष-फिर से शुरू की गई गतिविधि onTopResumedActivity(true) प्राप्त करने से पहले उसका निष्पादन पूरा कर लेती है, जब तक कि पिछली गतिविधि विधि कॉल को संभालने में बहुत अधिक समय न ले ले और 500 एमएस टाइमआउट तक न पहुंच जाए।

अनुकूलता

मल्टी-रेज़्यूमे लागू करते समय अनुकूलता बनाए रखने के लिए, इन समाधानों पर विचार करें।

एक ऐप प्रक्रिया में एकाधिक गतिविधियाँ फिर से शुरू हुईं

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

एक साथ कैमरा एक्सेस

• समस्याएँ । ये समस्याएँ Android 9 और उससे पहले के संस्करण में भी मौजूद हैं। उदाहरण के लिए, एक फुलस्क्रीन और फिर से शुरू की गई गतिविधि पिक्चर-इन-पिक्चर मोड में शीर्ष पर रुकी हुई गतिविधि के कारण कैमरा फोकस खो सकती है, लेकिन मल्टी-विंडो और मल्टी-डिस्प्ले मोड के व्यापक रूप से अपनाने के साथ अधिक उजागर हो जाती है।
  • RESUME स्थिति में किए गए परिवर्तनों के कारण, ऐप्स फिर से शुरू होने पर भी कैमरे से डिस्कनेक्ट हो सकते हैं। इसे संबोधित करने के लिए, ऐप्स को क्रैश हुए बिना कैमरा डिस्कनेक्ट को संभालना होगा। डिस्कनेक्ट होने पर, ऐप्स को डिस्कनेक्ट किया गया कॉलबैक मिलता है और एपीआई में सभी कॉल CameraAccessException फेंकना शुरू कर देते हैं।
  • resizeableActivity=false विशेष कैमरा एक्सेस की गारंटी नहीं है, क्योंकि कैमरे का उपयोग करने वाले अन्य ऐप्स अन्य डिस्प्ले पर खोले जा सकते हैं।
• समाधान। डेवलपर्स को किसी ऐप के कैमरे से डिस्कनेक्ट होने पर तर्क शामिल करना चाहिए। यदि कोई ऐप कैमरे से डिस्कनेक्ट हो गया है, तो उसे फिर से कनेक्ट करने और कैमरे का उपयोग जारी रखने का प्रयास करने के लिए कैमरा उपलब्धता कॉलबैक देखना चाहिए। मौजूदा CameraManager#AvailabilityCallback#onCameraAvailable() कॉलबैक के अलावा, एंड्रॉइड 10 ने CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() जोड़ा, जो उस स्थिति को कवर करता है जब फोकस (और कैमरा प्राथमिकता) कई फिर से शुरू की गई गतिविधियों के बीच स्विच करता है। ऐप डेवलपर्स को कैमरे तक पहुंच प्राप्त करने का अच्छा समय निर्धारित करने के लिए इन दोनों कॉलबैक का उपयोग करना चाहिए।

मल्टी-रेज़्यूमे

एंड्रॉइड 10 में, गतिविधि जीवनचक्र स्थिति दृश्यता और Z-क्रम द्वारा निर्धारित की जाती है। यह सुनिश्चित करने के लिए कि किसी गतिविधि पर दृश्यता के बाद सही स्थिति अपडेट हो और यह मूल्यांकन करें कि कौन सी जीवनचक्र स्थिति लागू है, विभिन्न स्थानों से ActivityRecord#makeActiveIfNeeded() विधि को लागू करें। एंड्रॉइड 10 में, सक्रिय का मतलब या तो RESUMED या PAUSED और केवल इन दो उदाहरणों में काम करता है।

एंड्रॉइड 10 में, किसी गतिविधि को फिर से शुरू करने को सिस्टम में एकल स्थान के बजाय प्रत्येक स्टैक में अलग से ट्रैक किया जाता है। ऐसा इसलिए है क्योंकि मल्टी-विंडो मोड में कई गतिविधि बदलाव एक साथ किए जा सकते हैं। विवरण के लिए, ActivityStack#mInResumeTopActivity देखें।

शीर्ष-फिर से शुरू की गई गतिविधि कॉलबैक

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

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

ग्राहकों को शीर्ष-पुनः शुरू किए गए राज्य परिवर्तनों की रिपोर्ट करने और एंड्रॉइड 9 से ActivityLifecycler आर्किटेक्चर का लाभ उठाने के लिए एक नया TopResumedActivityChangeItem लेनदेन आइटम जोड़ा गया था।

शीर्ष-फिर से शुरू की गई स्थिति को क्लाइंट साइड पर संग्रहीत किया जाता है, और हर बार जब गतिविधि फिर RESUMED या PAUSED तो यह यह भी जांचता है कि क्या onTopResumedActivityChanged() कॉलबैक लागू किया जाना चाहिए। यह जीवनचक्र स्थितियों और सर्वर और क्लाइंट पक्षों के बीच शीर्ष-पुनः शुरू की गई स्थिति के संचार में कुछ डिकॉउलिंग को सक्षम बनाता है।