व्यवहार में बदलाव: एपीआई 29+ को टारगेट करने वाले ऐप्लिकेशन

Android 10 में, सिस्टम के काम करने के तरीके में बदलाव किए गए हैं. इनसे आपके ऐप्लिकेशन पर असर पड़ सकता है. इस पेज पर बताए गए बदलाव, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो एपीआई 29 या उसके बाद के वर्शन को टारगेट करते हैं. अगर आपका ऐप्लिकेशन targetSdkVersion को "29" या इससे ज़्यादा पर सेट करता है, तो आपको अपने ऐप्लिकेशन में बदलाव करना चाहिए, ताकि जहां भी लागू हो वहां इन व्यवहारों को सही तरीके से काम किया जा सके.

ऐप्लिकेशन के काम करने के तरीके में हुए उन बदलावों की सूची भी देखना न भूलें जिनका असर Android 10 पर चल रहे सभी ऐप्लिकेशन पर पड़ता है.

SDK टूल के अलावा किसी दूसरे इंटरफ़ेस से जुड़ी पाबंदियों में अपडेट

ऐप्लिकेशन के काम करने और उसके साथ अन्य ऐप्लिकेशन के काम करने की सुविधा को पक्का करने के लिए, प्लैटफ़ॉर्म ने यह पाबंदी लगाना शुरू कर दिया है कि Android 9 (एपीआई लेवल 28) में आपका ऐप्लिकेशन, एसडीके टूल के अलावा किन इंटरफ़ेस का इस्तेमाल कर सकता है. Android 10 में, Android डेवलपर के साथ मिलकर किए गए काम और नई इंटरनल टेस्टिंग के आधार पर, पाबंदी वाले ऐसे इंटरफ़ेस की अपडेट की गई सूचियां शामिल हैं जो SDK टूल के नहीं हैं. हमारा मकसद यह पक्का करना है कि SDK टूल के बाहर के इंटरफ़ेस पर पाबंदी लगाने से पहले, सार्वजनिक विकल्प उपलब्ध हों.

अगर आपको Android 10 (एपीआई लेवल 29) को टारगेट नहीं करना है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, फ़िलहाल कुछ ऐसे इंटरफ़ेस इस्तेमाल किए जा सकते हैं जो SDK टूल के नहीं हैं. यह इस बात पर निर्भर करता है कि आपके ऐप्लिकेशन का टारगेट एपीआई लेवल क्या है. हालांकि, SDK टूल के अलावा किसी भी दूसरे तरीके या फ़ील्ड का इस्तेमाल करने पर, आपके ऐप्लिकेशन के काम न करने का खतरा हमेशा बना रहता है.

अगर आपको नहीं पता कि आपका ऐप्लिकेशन, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस का इस्तेमाल करता है या नहीं, तो इसकी पुष्टि करने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, SDK टूल के अलावा किसी अन्य इंटरफ़ेस पर निर्भर करता है, तो आपको SDK टूल के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. हालांकि, हम समझते हैं कि कुछ ऐप्लिकेशन में, गैर-SDK इंटरफ़ेस का इस्तेमाल करने के लिए मान्य उदाहरण हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, गैर-एसडीके इंटरफ़ेस का इस्तेमाल करने का कोई विकल्प नहीं मिलता है, तो आपको नए सार्वजनिक एपीआई का अनुरोध करना चाहिए.

ज़्यादा जानने के लिए, Android 10 में, SDK टूल के बाहर के इंटरफ़ेस से जुड़ी पाबंदियों में हुए अपडेट और SDK टूल के बाहर के इंटरफ़ेस पर लगी पाबंदियां देखें.

शेयर की गई मेमोरी

Ashmem ने /proc/<pid>/maps में dalvik maps का फ़ॉर्मैट बदल दिया है. इससे उन ऐप्लिकेशन पर असर पड़ता है जो सीधे maps फ़ाइल को पार्स करते हैं. ऐप्लिकेशन डेवलपर को Android 10 या उसके बाद के वर्शन वाले डिवाइसों पर, /proc/<pid>/maps फ़ॉर्मैट की जांच करनी चाहिए. साथ ही, अगर ऐप्लिकेशन, dalvik मैप फ़ॉर्मैट पर निर्भर करता है, तो उसके हिसाब से पार्स करना चाहिए.

Android 10 को टारगेट करने वाले ऐप्लिकेशन, सीधे तौर पर ashmem (/dev/ashmem) का इस्तेमाल नहीं कर सकते. इसके बजाय, उन्हें NDK के ASharedMemory क्लास के ज़रिए शेयर की गई मेमोरी को ऐक्सेस करना होगा. इसके अलावा, ऐप्लिकेशन मौजूदा ashmem फ़ाइल डिस्क्रिप्टर के लिए सीधे IOCTL नहीं कर सकते. इसके बजाय, उन्हें शेयर की गई मेमोरी के क्षेत्र बनाने के लिए, NDK की ASharedMemory क्लास या Android Java API का इस्तेमाल करना होगा. इस बदलाव से, शेयर की गई मेमोरी के साथ काम करते समय सुरक्षा और बेहतर परफ़ॉर्मेंस मिलती है. साथ ही, Android की परफ़ॉर्मेंस और सुरक्षा भी बेहतर होती है.

ऐप्लिकेशन की होम डायरेक्ट्री के लिए, 'कार्रवाई करने की अनुमति' हटाई गई

लिखने की अनुमति वाली ऐप्लिकेशन होम डायरेक्ट्री से फ़ाइलों को चलाना, W^X के उल्लंघन के दायरे में आता है. ऐप्लिकेशन में सिर्फ़ वह बाइनरी कोड लोड होना चाहिए जो ऐप्लिकेशन की APK फ़ाइल में एम्बेड किया गया है.

Android 10 को टारगेट करने वाले गैर-भरोसेमंद ऐप्लिकेशन, execve() सीधे तौर पर ऐप्लिकेशन की होम डायरेक्ट्री में मौजूद फ़ाइलों पर execve() इंवोक नहीं कर सकते.

इसके अलावा, Android 10 को टारगेट करने वाले ऐप्लिकेशन, dlopen() से खोली गई फ़ाइलों के एक्ज़ीक्यूटेबल कोड में, मेमोरी में बदलाव नहीं कर सकते. साथ ही, वे इन बदलावों को डिस्क में लिखने की उम्मीद भी नहीं कर सकते, क्योंकि लिखने लायक फ़ाइल डिस्क्रिप्टर की मदद से, लाइब्रेरी को PROT_EXEC पर मैप नहीं किया जा सकता. इसमें, टेक्स्ट को दूसरी जगह ले जाने वाली, शेयर की गई ऑब्जेक्ट (.so) फ़ाइलें भी शामिल हैं.

Android रनटाइम सिर्फ़ सिस्टम से जनरेट की गई OAT फ़ाइलें स्वीकार करता है

Android रनटाइम (ART) अब ऐप्लिकेशन प्रोसेस से dex2oat को कॉल नहीं करता. इस बदलाव का मतलब है कि ART सिर्फ़ ऐसी OAT फ़ाइलें स्वीकार करेगा जिन्हें सिस्टम ने जनरेट किया है.

ART में AOT की सटीक जानकारी लागू करना

पहले, Android Runtime (ART) के ज़रिए, पहले से (AOT) कंपाइल करने की सुविधा की वजह से, रनटाइम क्रैश हो सकते थे. ऐसा तब होता था, जब कंपाइल करने के समय और रनटाइम के समय क्लासपथ एनवायरमेंट एक जैसा नहीं होता था. Android 10 और इसके बाद के वर्शन के लिए, इन एनवायरमेंट कॉन्टेक्स्ट के एक जैसे होने की ज़रूरत होती है. इस वजह से, व्यवहार में ये बदलाव होते हैं:

• कस्टम क्लास लोडर, AOT से कंपाइल नहीं होते. ये ऐसे क्लास लोडर होते हैं जिन्हें ऐप्लिकेशन लिखते हैं. ये dalvik.system पैकेज के क्लास लोडर से अलग होते हैं. ऐसा इसलिए है, क्योंकि रनटाइम के दौरान, एआरटी को कस्टमाइज़ की गई क्लास लुकअप लागू करने के बारे में पता नहीं चलता.
• सेकंडरी dex फ़ाइलें, बैकग्राउंड में AOT-कंपाइल की जाती हैं. ये ऐसी dex फ़ाइलें होती हैं जिन्हें मुख्य APK में शामिल ऐप्लिकेशन मैन्युअल तरीके से लोड करते हैं. ऐसा इसलिए है, क्योंकि पहली बार इस्तेमाल करने के लिए, कॉम्पाइलेशन की प्रोसेस बहुत महंगी हो सकती है. इससे, प्रोग्राम को चलाने से पहले, अनचाहे इंतज़ार का समय भी बढ़ सकता है. ध्यान दें कि ऐप्लिकेशन के लिए, स्प्लिट का इस्तेमाल करने और सेकंडरी इंडेक्स फ़ाइलों का इस्तेमाल बंद करने का सुझाव दिया जाता है.
• Android में शेयर की गई लाइब्रेरी (Android मेनिफ़ेस्ट में <library> और <uses-library> एंट्री), प्लैटफ़ॉर्म के पिछले वर्शन में इस्तेमाल किए गए क्लास लोडर के क्रम के बजाय, किसी अलग क्लास लोडर के क्रम का इस्तेमाल करके लागू की जाती हैं.

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

Android 10 या उसके बाद के वर्शन को टारगेट करने वाले और फ़ुल-स्क्रीन इंटेंट वाली सूचनाओं का इस्तेमाल करने वाले ऐप्लिकेशन को, अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में USE_FULL_SCREEN_INTENT अनुमति का अनुरोध करना होगा. यह सामान्य अनुमति है. इसलिए, सिस्टम अनुरोध करने वाले ऐप्लिकेशन को यह अनुमति अपने-आप देता है.

अगर Android 10 या उसके बाद के वर्शन को टारगेट करने वाला कोई ऐप्लिकेशन, ज़रूरी अनुमति का अनुरोध किए बिना फ़ुल स्क्रीन इंटेंट की मदद से सूचना बनाने की कोशिश करता है, तो सिस्टम फ़ुल स्क्रीन इंटेंट को अनदेखा कर देता है और यह लॉग मैसेज दिखाता है:

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

फ़ोल्डेबल डिवाइसों के लिए सहायता

Android 10 में ऐसे बदलाव किए गए हैं जिनसे फ़ोल्ड किए जा सकने वाले और बड़ी स्क्रीन वाले डिवाइसों पर बेहतर अनुभव मिलता है.

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

"फ़ोकस" को "फिर से शुरू की गई सबसे ऊपर की" गतिविधि के साथ न जोड़ें. सिस्टम, z-order के आधार पर ऐक्टिविटी को प्राथमिकता देता है. इससे उन ऐक्टिविटी को ज़्यादा प्राथमिकता मिलती है जिनके साथ उपयोगकर्ता ने पिछली बार इंटरैक्ट किया था. किसी गतिविधि को फिर से शुरू किया जा सकता है, लेकिन उस पर फ़ोकस नहीं किया जा सकता. उदाहरण के लिए, अगर सूचना शेड को बड़ा किया गया है.

Android 10 (एपीआई लेवल 29) और उसके बाद के वर्शन में, onTopResumedActivityChanged() कॉलबैक की सदस्यता ली जा सकती है. इससे, आपको यह सूचना मिलेगी कि आपकी गतिविधि फिर से शुरू होने पर, वह सबसे ऊपर की पोज़िशन पर है या नहीं. यह Android 10 से पहले, फिर से शुरू होने की स्थिति के बराबर है. अगर आपका ऐप्लिकेशन खास या सिंगलटन संसाधनों का इस्तेमाल कर रहा है, तो यह जानकारी एक संकेत के तौर पर काम आ सकती है. इन संसाधनों को दूसरे ऐप्लिकेशन के साथ शेयर करना पड़ सकता है.

resizeableActivity मेनिफ़ेस्ट एट्रिब्यूट के काम करने का तरीका भी बदल गया है. अगर कोई ऐप्लिकेशन Android 10 (एपीआई लेवल 29) या उसके बाद के वर्शन में resizeableActivity=false सेट करता है, तो उपलब्ध स्क्रीन साइज़ में बदलाव होने पर या ऐप्लिकेशन को एक स्क्रीन से दूसरी स्क्रीन पर ले जाने पर, उसे काम करने के तरीके के हिसाब से मोड में रखा जा सकता है.

ऐप्लिकेशन, Android 10 में पेश किए गए android:minAspectRatio एट्रिब्यूट का इस्तेमाल करके, उन स्क्रीन रेशियो के बारे में बता सकते हैं जिन पर आपका ऐप्लिकेशन काम करता है.

Android Studio के 3.5 वर्शन से, एमुलेटर टूल में 7.3" और 8" वर्चुअल डिवाइस शामिल हैं. इनकी मदद से, बड़े डिवाइसों पर अपने कोड की जांच की जा सकती है.

ज़्यादा जानकारी के लिए, फ़ोल्ड किए जा सकने वाले डिवाइसों के लिए अपने ऐप्लिकेशन डिज़ाइन करना लेख पढ़ें.