Android 10 में, सिस्टम के काम करने के तरीके में बदलाव किए गए हैं. इनसे आपके ऐप्लिकेशन पर असर पड़ सकता है. इस पेज पर बताए गए बदलाव, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो एपीआई 29 या उसके बाद के वर्शन को टारगेट करते हैं. अगर आपका ऐप्लिकेशन targetSdkVersion को "29" या इससे ज़्यादा पर सेट करता है, तो आपको अपने ऐप्लिकेशन में बदलाव करना चाहिए, ताकि जहां भी लागू हो वहां इन व्यवहारों को सही तरीके से काम किया जा सके.
ऐप्लिकेशन के काम करने के तरीके में हुए उन बदलावों की सूची भी देखना न भूलें जिनका असर Android 10 पर चल रहे सभी ऐप्लिकेशन पर पड़ता है.
ध्यान दें: इस पेज पर बताए गए बदलावों के अलावा, Android 10 में कई निजता से जुड़े बदलाव और पाबंदियां भी शामिल की गई हैं. इनमें ये शामिल हैं:
- डिवाइस का स्कोप किया गया स्टोरेज
- USB डिवाइस का सीरियल नंबर ऐक्सेस करना
- वाई-फ़ाई को चालू, बंद, और कॉन्फ़िगर करने की सुविधा
- कनेक्टिविटी एपीआई के लिए जगह की जानकारी की अनुमतियां
इन बदलावों का असर, एपीआई लेवल 29 या उससे ज़्यादा के वर्शन को टारगेट करने वाले ऐप्लिकेशन पर पड़ेगा. इससे, उपयोगकर्ता की निजता को बेहतर बनाने में मदद मिलेगी. इन बदलावों को लागू करने के तरीके के बारे में ज़्यादा जानने के लिए, निजता से जुड़े बदलाव पेज पर जाएं.
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-क्रम के आधार पर ऐक्टिविटी को प्राथमिकता देता है. इससे उन ऐक्टिविटी को ज़्यादा प्राथमिकता मिलती है जिनके साथ उपयोगकर्ता ने पिछली बार इंटरैक्ट किया था. किसी गतिविधि को फिर से शुरू किया जा सकता है, लेकिन उस पर फ़ोकस नहीं किया जा सकता. उदाहरण के लिए, अगर सूचना शेड को बड़ा किया गया है.
Android 10 (एपीआई लेवल 29) और उसके बाद के वर्शन में, onTopResumedActivityChanged() कॉलबैक की सदस्यता ली जा सकती है. इससे, आपको यह सूचना मिलेगी कि आपकी गतिविधि फिर से शुरू होने पर, वह सबसे ऊपर की पोज़िशन पर है या नहीं. यह Android 10 से पहले के ऐप्लिकेशन के फिर से शुरू होने की स्थिति के बराबर है. अगर आपका ऐप्लिकेशन खास या सिंगलटन संसाधनों का इस्तेमाल कर रहा है, तो यह जानकारी एक संकेत के तौर पर काम आ सकती है. इन संसाधनों को दूसरे ऐप्लिकेशन के साथ शेयर करना पड़ सकता है.
resizeableActivity
मेनिफ़ेस्ट एट्रिब्यूट के काम करने का तरीका भी बदल गया है. अगर कोई ऐप्लिकेशन Android 10 (एपीआई लेवल 29) या उसके बाद के वर्शन में resizeableActivity=false सेट करता है, तो उपलब्ध स्क्रीन साइज़ बदलने पर या ऐप्लिकेशन को एक स्क्रीन से दूसरी स्क्रीन पर ले जाने पर, उसे कंपैटबिलिटी मोड में डाला जा सकता है.
ऐप्लिकेशन, Android 10 में पेश किए गए android:minAspectRatio एट्रिब्यूट का इस्तेमाल करके, उन स्क्रीन रेशियो के बारे में बता सकते हैं जिन पर आपका ऐप्लिकेशन काम करता है.
Android Studio के 3.5 वर्शन से, एमुलेटर टूल में 7.3" और 8" वर्चुअल डिवाइस शामिल हैं. इनकी मदद से, बड़ी स्क्रीन पर अपने कोड की जांच की जा सकती है.
ज़्यादा जानकारी के लिए, फ़ोल्ड किए जा सकने वाले डिवाइसों के लिए अपने ऐप्लिकेशन डिज़ाइन करना लेख पढ़ें.