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

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

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 स्थिति में जा सके. उदाहरण के लिए, मल्टी-विंडो मोड में. यह कॉलबैक ज़रूरी नहीं है. इसलिए, यह गतिविधि के लाइफ़साइकल का हिस्सा नहीं है. इसका इस्तेमाल कभी-कभार ही किया जाना चाहिए.

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

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

एक से ज़्यादा रीज़्यूमे लागू करते समय, इन समाधानों का इस्तेमाल करें, ताकि वे सभी डिवाइसों पर काम करते रहें.

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

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

एक साथ कई डिवाइसों से कैमरे का ऐक्सेस

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