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

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

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

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

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

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

नॉन-एसडीके इंटरफ़ेस से जुड़ी पाबंदियों में अपडेट

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

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

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

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

साझा मेमोरी

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

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

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

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

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

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

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

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

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

पहले, Android रनटाइम (एआरटी) की ओर से की जाने वाली अहेड-ऑफ़-टाइम (एओटी) कंपाइलेशन की वजह से, रनटाइम क्रैश हो सकता था. ऐसा तब होता था, जब कंपाइल के समय और रनटाइम के दौरान क्लासपाथ एनवायरमेंट एक जैसा न हो. Android 10 और इसके बाद के वर्शन के लिए, यह ज़रूरी है कि एनवायरमेंट के ये कॉन्टेक्स्ट हमेशा एक जैसे हों. इससे, व्यवहार में ये बदलाव होते हैं:

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

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