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

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

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

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

• डिवाइस का स्कोप किया गया स्टोरेज
• USB डिवाइस के सीरियल नंबर को ऐक्सेस करने की अनुमति
• वाई-फ़ाई को चालू, बंद, और कॉन्फ़िगर करने की सुविधा
• कनेक्टिविटी एपीआई के लिए जगह की जानकारी की अनुमतियां

ये बदलाव, एपीआई लेवल 29 या इससे ऊपर के लेवल को टारगेट करने वाले ऐप्लिकेशन पर लागू होते हैं. इनसे उपयोगकर्ता की निजता को बेहतर बनाया जाता है. इन बदलावों को लागू करने के तरीके के बारे में ज़्यादा जानने के लिए, निजता से जुड़े बदलाव पेज देखें.

ऐसे इंटरफ़ेस के इस्तेमाल पर पाबंदियों से जुड़े अपडेट जो SDK टूल में उपलब्ध नहीं है

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

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

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

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

शेयर की गई यादें

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

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

ऐप्लिकेशन की होम डायरेक्ट्री के लिए, फ़ाइलें चलाने की अनुमति हटा दी गई है

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

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

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

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

Android रनटाइम (एआरटी), अब ऐप्लिकेशन प्रोसेस से dex2oat को शुरू नहीं करता है. इस बदलाव का मतलब है कि एआरटी सिर्फ़ उन ओएटी फ़ाइलों को स्वीकार करेगा जिन्हें सिस्टम ने जनरेट किया है.

ART में एओटी की सही जानकारी लागू करना

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

• कस्टम क्लास लोडर, एओटी-कंपाइल नहीं किए जाते. ये क्लास लोडर, ऐप्लिकेशन लिखते हैं. ये dalvik.system पैकेज के क्लास लोडर से अलग होते हैं. ऐसा इसलिए है, क्योंकि ART को रनटाइम के दौरान, क्लास लुकअप के कस्टम तरीके के बारे में पता नहीं चल सकता.
• सेकंडरी डेक्स फ़ाइलें, यानी कि प्राइमरी 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-ऑर्डर के आधार पर ऐक्टिविटी को प्राथमिकताएं असाइन करता है, ताकि उन ऐक्टिविटी को ज़्यादा प्राथमिकता दी जा सके जिनके साथ उपयोगकर्ता ने हाल ही में इंटरैक्ट किया है. किसी गतिविधि को टॉप-रिज़्यूम किया जा सकता है, लेकिन उस पर फ़ोकस नहीं किया जा सकता. उदाहरण के लिए, अगर सूचना पैनल बड़ा किया गया है.

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

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

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

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

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