एक से ज़्यादा बार फिर से शुरू करना

Android 9 और इससे पहले के वर्शन में, ऐप्लिकेशन को PAUSED स्थिति में तब रखा जाता था, जब:

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

इन स्थितियों में, ऐप्लिकेशन को अलग-अलग समय के लिए रोकना पड़ता है. हालांकि, ऐप्लिकेशन लेवल पर इनमें अंतर नहीं किया जा सकता.

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

• स्प्लिट-स्क्रीन मोड में चल रही दोनों गतिविधियां फिर से शुरू हो जाती हैं.
• फ़्री-फ़ॉर्म विंडो मोड में सबसे ऊपर दिखने वाली सभी गतिविधियां फिर से शुरू हो जाती हैं.
• एक साथ कई स्क्रीन पर की गई गतिविधियों को फिर से शुरू किया जा सकता है.

पहली इमेज. फ़ोल्ड किए जा सकने वाले डिवाइस पर मल्टी-रिज़्यूम की सुविधा

दूसरी इमेज. डेस्कटॉप मोड में एक साथ कई वीडियो फिर से शुरू करना

गतिविधियां PAUSED स्थिति में तब हो सकती हैं, जब उन पर फ़ोकस न किया जा सके या वे आंशिक रूप से ढकी हुई हों. जैसे:

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

इस तरीके से ऐप्लिकेशन को यह पता चलता है कि कोई गतिविधि, सिर्फ़ RESUMED स्थिति में उपयोगकर्ता से इनपुट पा सकती है. Android 10 से पहले, ऐक्टिविटी को PAUSED स्थिति में भी इनपुट मिल सकता था. उदाहरण के लिए, Android 9 चलाने वाले डिवाइस पर स्प्लिट-स्क्रीन मोड में दोनों ऐक्टिविटी को एक साथ टच करके देखें.

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

Activity#onTopResumedActivityChanged(boolean onTop)

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

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

इनके साथ काम करता है

मल्टी-रिज़्यूम की सुविधा लागू करते समय, यह पक्का करें कि यह सुविधा अन्य सुविधाओं के साथ काम करे. इसके लिए, इन समाधानों को आज़माएं.

एक ऐप्लिकेशन प्रोसेस में कई गतिविधियां फिर से शुरू की गई हैं

• समस्या. Android 9 और इससे पहले वाले वर्शन में, सिस्टम में मौजूद सिर्फ़ एक गतिविधि को एक बार में फिर से शुरू किया जाता है. एक गतिविधि से दूसरी गतिविधि पर स्विच करने के दौरान, एक गतिविधि को रोका जाता है और फिर दूसरी गतिविधि को शुरू किया जाता है. कुछ ऐप्लिकेशन और फ़्रेमवर्क (जैसे, Flutter या Android का LocalActivityManager) इस फ़ैक्ट का इस्तेमाल करते हैं. साथ ही, फिर से शुरू की गई गतिविधि की स्थिति को सिंगलटन में सेव करते हैं.
• समस्या हल करने का तरीका. Android 9 और इससे पहले के वर्शन में, अगर एक ही प्रोसेस की दो गतिविधियां फिर से शुरू की जाती हैं, तो सिस्टम सिर्फ़ उस गतिविधि को फिर से शुरू करता है जो Z-ऑर्डर में सबसे ऊपर होती है. Android 10 को टारगेट करने वाले ऐप्लिकेशन, एक साथ कई ऐक्टिविटी को फिर से शुरू करने की सुविधा दे सकते हैं.

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

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

एक से ज़्यादा बार फिर से शुरू करना

Android 10 में, ऐक्टिविटी की लाइफ़साइकल की स्थिति, दिखने की स्थिति और Z-ऑर्डर से तय होती है. यह पक्का करने के लिए कि ऐक्टिविटी पर दिखने से जुड़े अपडेट के बाद सही स्थिति दिखे और यह पता लगाने के लिए कि लाइफ़साइकल की कौनसी स्थिति लागू होती है, अलग-अलग जगहों से ActivityRecord#makeActiveIfNeeded() मेथड को शुरू करें. Android 10 में, ऐक्टिव का मतलब RESUMED या PAUSED होता है. यह सिर्फ़ इन दो स्थितियों में काम करता है.

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

सबसे ज़्यादा समय लेने वाला गतिविधि कॉलबैक

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

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

क्लाइंट को टॉप-रिज़्यूम की गई स्थिति में होने वाले बदलावों की जानकारी देने के लिए, नया TopResumedActivityChangeItem लेन-देन आइटम जोड़ा गया है. यह Android 9 के ActivityLifecycler आर्किटेक्चर का इस्तेमाल करता है.

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