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

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() कॉलबैक को शुरू किया जाना चाहिए या नहीं. इससे, सर्वर और क्लाइंट साइड के बीच लाइफ़साइकल की स्थितियों और फिर से शुरू की गई स्थिति के कम्यूनिकेशन में कुछ अलग-अलग चीज़ें शामिल की जा सकती हैं.