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

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