एपीआई लेवल: 21
Android 5.0 में नई सुविधाओं और क्षमताओं के साथ-साथ, सिस्टम में कई तरह के बदलाव और एपीआई के काम करने के तरीके में बदलाव किए गए हैं. इस दस्तावेज़ में, कुछ अहम बदलावों के बारे में बताया गया है. आपको इन बदलावों को समझना चाहिए और अपने ऐप्लिकेशन में इनका ध्यान रखना चाहिए.
अगर आपने पहले Android के लिए कोई ऐप्लिकेशन पब्लिश किया है, तो ध्यान रखें कि Android 5.0 में किए गए इन बदलावों का आपके ऐप्लिकेशन पर असर पड़ सकता है.
प्लैटफ़ॉर्म की नई सुविधाओं के बारे में खास जानकारी पाने के लिए, Android Lollipop की हाइलाइट देखें.
वीडियो
डेवलपर के लिए खास जानकारी: Android 5.0 में नया क्या है
डेवलपर के लिए खास जानकारी: सूचनाएं
Android रनटाइम (ART)
Android 5.0 में, ART रनटाइम, प्लैटफ़ॉर्म के डिफ़ॉल्ट रनटाइम के तौर पर Dalvik की जगह ले लेता है. ART रनटाइम को Android 4.4 में, एक्सपेरिमेंट के तौर पर लॉन्च किया गया था.
ART की नई सुविधाओं के बारे में खास जानकारी पाने के लिए, ART के बारे में जानकारी देखें. नई सुविधाओं में ये शामिल हैं:
- पहले से कंपाइल करना (एएओटी)
- बेहतर गारबेज कलेक्शन (जीसी)
- डीबग करने के लिए बेहतर सहायता
ज़्यादातर Android ऐप्लिकेशन, ART में बिना किसी बदलाव के काम करने चाहिए. हालांकि, Dalvik पर काम करने वाली कुछ तकनीकें, ART पर काम नहीं करतीं. सबसे ज़रूरी समस्याओं के बारे में जानकारी पाने के लिए, Android Runtime (ART) पर ऐप्लिकेशन के व्यवहार की पुष्टि करना लेख पढ़ें. खास तौर पर इन बातों पर ध्यान दें:
- आपका ऐप्लिकेशन, C/C++ कोड चलाने के लिए Java Native Interface (JNI) का इस्तेमाल करता है.
- डेवलपमेंट टूल का इस्तेमाल किया जाता है, जो स्टैंडर्ड कोड जनरेट करते हैं. जैसे, कुछ obfuscators.
- आपने ऐसी तकनीकों का इस्तेमाल किया हो जो कचरा इकट्ठा करने के लिए, कम जगह में ज़्यादा कचरा इकट्ठा करने की सुविधा के साथ काम नहीं करती हैं.
सूचनाएं
पक्का करें कि आपकी सूचनाएं, Android 5.0 में हुए इन बदलावों को ध्यान में रखती हों. Android 5.0 और इसके बाद के वर्शन के लिए, सूचनाओं को डिज़ाइन करने के बारे में ज़्यादा जानने के लिए, सूचनाओं के डिज़ाइन से जुड़ी गाइड देखें.
मटीरियल डिज़ाइन स्टाइल
सूचनाओं को सफ़ेद (या बहुत हल्के) बैकग्राउंड पर गहरे रंग के टेक्स्ट के साथ दिखाया जाता है, ताकि वे मटीरियल डिज़ाइन वाले नए विजेट से मेल खा सकें. पक्का करें कि नई कलर स्कीम के साथ, आपकी सभी सूचनाएं सही दिख रही हों. अगर आपको सूचनाएं गलत दिख रही हैं, तो उन्हें ठीक करें:
- अपने आइकॉन की इमेज के पीछे सर्कल में एक्सेंट कलर सेट करने के लिए,
setColor()का इस्तेमाल करें. - रंग वाली ऐसेट को अपडेट करें या हटाएं. सिस्टम, ऐक्शन आइकॉन और मुख्य सूचना आइकॉन में, सभी ऐसे चैनलों को अनदेखा करता है जो अक्षर नहीं हैं. आपको यह मान लेना चाहिए कि ये आइकॉन सिर्फ़ अक्षर वाले होंगे. सिस्टम, सूचना के आइकॉन को सफ़ेद रंग में और कार्रवाई के आइकॉन को डार्क ग्रे रंग में दिखाता है.
आवाज़ और वाइब्रेशन
अगर फ़िलहाल Ringtone, MediaPlayer या Vibrator क्लास का इस्तेमाल करके, सूचनाओं में आवाज़ और वाइब्रेशन जोड़े जा रहे हैं, तो यह कोड हटाएं. इससे सिस्टम, प्राथमिकता मोड में सूचनाओं को सही तरीके से दिखा पाएगा. इसके बजाय, आवाज़ और कंपन जोड़ने के लिए,
Notification.Builder तरीकों का इस्तेमाल करें.
डिवाइस को RINGER_MODE_SILENT पर सेट करने से, डिवाइस नए प्राथमिकता मोड में चला जाता है. अगर डिवाइस को RINGER_MODE_NORMAL या RINGER_MODE_VIBRATE पर सेट किया जाता है, तो वह प्राथमिकता मोड से बाहर हो जाता है.
पहले, Android टैबलेट डिवाइसों पर वॉल्यूम कंट्रोल करने के लिए, STREAM_MUSIC को मुख्य स्ट्रीम के तौर पर इस्तेमाल करता था. Android 5.0 में, फ़ोन और टैबलेट, दोनों डिवाइसों के लिए अब एक ही मास्टरवॉल्यूम स्ट्रीम है. इसे STREAM_RING या STREAM_NOTIFICATION से कंट्रोल किया जाता है.
लॉक स्क्रीन पर दिखने की सेटिंग
Android 5.0 में, सूचनाएं अब डिफ़ॉल्ट रूप से उपयोगकर्ता की लॉक स्क्रीन पर दिखती हैं.
उपयोगकर्ता, संवेदनशील जानकारी को ज़ाहिर होने से बचाने का विकल्प चुन सकते हैं. ऐसा करने पर, सिस्टम सूचना में दिखने वाले टेक्स्ट को अपने-आप छिपा देता है. हटाए गए हिस्से वाली इस सूचना को पसंद के मुताबिक बनाने के लिए, setPublicVersion() का इस्तेमाल करें.
अगर सूचना में निजी जानकारी शामिल नहीं है या आपको सूचना पर मीडिया चलाने की अनुमति देनी है, तो setVisibility() तरीका VISIBILITY_PUBLIC पर सेट करें.
मीडिया प्लेबैक
अगर आपको मीडिया चलाने की स्थिति या ट्रांसपोर्ट कंट्रोल दिखाने वाली सूचनाएं लागू करनी हैं, तो कस्टम RemoteViews.RemoteView ऑब्जेक्ट के बजाय नए Notification.MediaStyle टेंप्लेट का इस्तेमाल करें. कोई भी तरीका चुनें, सूचना दिखने की सेटिंग को VISIBILITY_PUBLIC पर सेट करना न भूलें, ताकि लॉक स्क्रीन से आपके कंट्रोल ऐक्सेस किए जा सकें. ध्यान दें कि Android 5.0 से, सिस्टम अब लॉक स्क्रीन पर RemoteControlClient ऑब्जेक्ट नहीं दिखाता. ज़्यादा जानकारी के लिए, अगर आपका ऐप्लिकेशन RemoteControlClient का इस्तेमाल करता है लेख पढ़ें.
स्क्रीन पर सबसे ऊपर सूचना देने वाला कार्ड
डिवाइस के ऐक्टिव होने पर, सूचनाएं अब एक छोटी फ़्लोटिंग विंडो में दिख सकती हैं. इसे हेड्स-अप सूचना भी कहा जाता है. डिवाइस के ऐक्टिव होने का मतलब है कि डिवाइस अनलॉक हो और उसकी स्क्रीन चालू हो. ये सूचनाएं, सूचना के कॉम्पैक्ट फ़ॉर्म की तरह ही दिखती हैं. हालांकि, हेड्स-अप सूचना में ऐक्शन बटन भी दिखते हैं. उपयोगकर्ता, मौजूदा ऐप्लिकेशन से बाहर निकले बिना, हेड्स-अप सूचना पर कार्रवाई कर सकते हैं या उसे खारिज कर सकते हैं.
स्क्रीन पर सबसे ऊपर सूचनाएं देने वाले कार्ड को ट्रिगर करने वाली स्थितियों के उदाहरण:
- उपयोगकर्ता की गतिविधि फ़ुलस्क्रीन मोड में है (ऐप्लिकेशन में
fullScreenIntentका इस्तेमाल किया जाता है) - सूचना की प्राथमिकता ज़्यादा हो और उसमें रिंगटोन या वाइब्रेशन का इस्तेमाल किया गया हो
अगर आपका ऐप्लिकेशन इनमें से किसी भी स्थिति में सूचनाएं दिखाता है, तो पक्का करें कि स्क्रीन पर सबसे ऊपर सूचनाएं देने वाले कार्ड सही तरीके से दिखाए जाएं.
मीडिया कंट्रोल और RemoteControlClient
RemoteControlClient क्लास अब काम नहीं करती. जल्द से जल्द
नए MediaSession API पर स्विच करें.
Android 5.0 की लॉक स्क्रीन पर, MediaSession या RemoteControlClient के लिए, यात्रा के कंट्रोल नहीं दिखते. इसके बजाय, आपका ऐप्लिकेशन सूचना के ज़रिए, लॉक स्क्रीन से मीडिया चलाने की सुविधा दे सकता है. इससे, आपके ऐप्लिकेशन को मीडिया बटन दिखाने के तरीके पर ज़्यादा कंट्रोल मिलता है. साथ ही, लॉक और अनलॉक किए गए डिवाइसों पर, उपयोगकर्ताओं को एक जैसा अनुभव मिलता है.
Android 5.0 में, इस काम के लिए एक नया
Notification.MediaStyle टेंप्लेट जोड़ा गया है.
Notification.MediaStyle, Notification.Builder.addAction() की मदद से जोड़ी गई सूचना ऐक्शन को, आपके ऐप्लिकेशन के मीडिया चलाने से जुड़ी सूचनाओं में एम्बेड किए गए कॉम्पैक्ट बटन में बदल देता है. सिस्टम को यह बताने के लिए कि यह सूचना किसी मौजूदा मीडिया सेशन को कंट्रोल करती है, अपने सेशन टोकन को setSession() तरीके में पास करें.
सूचना को किसी भी लॉक स्क्रीन पर दिखने के लिए सुरक्षित के तौर पर मार्क करने के लिए, सूचना के दिखने की सेटिंग को VISIBILITY_PUBLIC पर सेट करना न भूलें. ज़्यादा जानकारी के लिए, लॉक स्क्रीन पर सूचनाएं लेख पढ़ें.
अगर आपका ऐप्लिकेशन Android TV या Wear प्लैटफ़ॉर्म पर चल रहा है, तो मीडिया प्लेबैक कंट्रोल दिखाने के लिए, MediaSession क्लास लागू करें. अगर आपके ऐप्लिकेशन को Android डिवाइसों पर मीडिया बटन इवेंट पाने हैं, तो आपको MediaSession को भी लागू करना चाहिए.
getRecentTasks()
Android 5.0 में एक साथ कई दस्तावेज़ों और गतिविधियों के टास्क की नई सुविधा लॉन्च की गई है. इस सुविधा के बारे में जानने के लिए, यहां हाल ही में इस्तेमाल किए गए दस्तावेज़ों और गतिविधियों की स्क्रीन पर एक साथ कई दस्तावेज़ और गतिविधियां देखें. उपयोगकर्ता की निजता को बेहतर बनाने के लिए, ActivityManager.getRecentTasks() का तरीका अब बंद कर दिया गया है. पुराने वर्शन के साथ काम करने के लिए, यह तरीका अब भी अपने डेटा का एक छोटा सबसेट दिखाता है. इसमें कॉल करने वाले ऐप्लिकेशन के टास्क और होम जैसे कुछ ऐसे टास्क शामिल हो सकते हैं जो संवेदनशील नहीं हैं. अगर आपका ऐप्लिकेशन अपने टास्क हासिल करने के लिए इस तरीके का इस्तेमाल कर रहा है, तो उस जानकारी को हासिल करने के लिए getAppTasks() का इस्तेमाल करें.
Android NDK में 64-बिट वाले डिवाइसों के लिए सहायता
Android 5.0 में 64-बिट सिस्टम के लिए सहायता उपलब्ध है. 64-बिट वर्शन में, ऐप्लिकेशन के लिए ज़्यादा जगह उपलब्ध होती है और परफ़ॉर्मेंस बेहतर होती है. साथ ही, यह मौजूदा 32-बिट ऐप्लिकेशन के साथ भी काम करता है. 64-बिट के साथ काम करने की सुविधा से, क्रिप्टोग्राफ़ी के लिए OpenSSL की परफ़ॉर्मेंस भी बेहतर होती है. इसके अलावा, इस रिलीज़ में नए नेटिव मीडिया एनडीके एपीआई के साथ-साथ, नेटिव OpenGL ES (GLES) 3.1 की सुविधा भी जोड़ी गई है.
Android 5.0 में दी गई 64-बिट सुविधा का इस्तेमाल करने के लिए, Android NDK पेज से NDK के रिव्यूज़न 10c को डाउनलोड और इंस्टॉल करें. NDK में हुए अहम बदलावों और गड़बड़ियों को ठीक करने के बारे में ज़्यादा जानने के लिए, रिविज़न 10c के रिलीज़ नोट देखें.
किसी सेवा से बाइंड करना
अब Context.bindService() के लिए, एक्सप्लिसिट Intent की ज़रूरत है. इंप्लिसिट इंटेंट देने पर, अपवाद दिखता है.
अपने ऐप्लिकेशन को सुरक्षित रखने के लिए, Service को शुरू या बांधते समय साफ़ तौर पर इंटेंट का इस्तेमाल करें. साथ ही, सेवा के लिए इंटेंट फ़िल्टर का एलान न करें.
WebView
Android 5.0, आपके ऐप्लिकेशन के डिफ़ॉल्ट व्यवहार में बदलाव करता है.
- अगर आपका ऐप्लिकेशन, एपीआई लेवल 21 या उससे ज़्यादा को टारगेट करता है, तो:
- सिस्टम, डिफ़ॉल्ट रूप से मिश्रित कॉन्टेंट और तीसरे पक्ष की कुकी को ब्लॉक करता है. अलग-अलग तरह के कॉन्टेंट और तीसरे पक्ष की कुकी को अनुमति देने के लिए,
setMixedContentMode()औरsetAcceptThirdPartyCookies()तरीकों का इस्तेमाल करें. - अब सिस्टम, एचटीएमएल दस्तावेज़ के उन हिस्सों को चुनता है जिन्हें ड्रॉ करना है. डिफ़ॉल्ट तौर पर लागू होने वाले इस नए व्यवहार से, मेमोरी फ़ुटप्रिंट को कम करने और परफ़ॉर्मेंस को बेहतर बनाने में मदद मिलती है. अगर आपको पूरे दस्तावेज़ को एक साथ रेंडर करना है, तो
enableSlowWholeDocumentDraw()को कॉल करके इस ऑप्टिमाइज़ेशन को बंद करें.
- सिस्टम, डिफ़ॉल्ट रूप से मिश्रित कॉन्टेंट और तीसरे पक्ष की कुकी को ब्लॉक करता है. अलग-अलग तरह के कॉन्टेंट और तीसरे पक्ष की कुकी को अनुमति देने के लिए,
- अगर आपका ऐप्लिकेशन 21 से पहले के एपीआई लेवल को टारगेट करता है, तो: सिस्टम, अलग-अलग तरह के कॉन्टेंट और तीसरे पक्ष की कुकी को अनुमति देता है. साथ ही, वह हमेशा पूरे दस्तावेज़ को एक साथ रेंडर करता है.
कस्टम अनुमतियों के लिए यूनीक होने की ज़रूरी शर्त
अनुमतियों के बारे में खास जानकारी में बताया गया है कि Android ऐप्लिकेशन, कॉन्फ़िगर किए जा सकने वाले कॉम्पोनेंट के ऐक्सेस को मैनेज करने के लिए, पसंद के मुताबिक अनुमतियां तय कर सकते हैं. ऐसा, प्लैटफ़ॉर्म की पहले से तय की गई सिस्टम अनुमतियों का इस्तेमाल किए बिना किया जा सकता है. ऐप्लिकेशन, अपनी मेनिफ़ेस्ट फ़ाइलों में बताए गए
<permission> एलिमेंट में कस्टम अनुमतियां तय करते हैं.
कुछ मामलों में, पसंद के मुताबिक अनुमतियां तय करना एक सही और सुरक्षित तरीका होता है. हालांकि, कभी-कभी कस्टम अनुमतियां बनाना ज़रूरी नहीं होता. साथ ही, अनुमतियों के लिए तय किए गए सुरक्षा लेवल के आधार पर, किसी ऐप्लिकेशन को खतरा भी हो सकता है.
Android 5.0 में, ऐप्लिकेशन के व्यवहार में बदलाव किया गया है. इससे यह पक्का किया जा सकता है कि किसी कस्टम अनुमति को सिर्फ़ एक ऐप्लिकेशन तय कर सकता है. ऐसा तब तक होगा, जब तक कि उस ऐप्लिकेशन को उसी पासकोड से साइन न किया गया हो जिससे अनुमति तय करने वाले दूसरे ऐप्लिकेशन को साइन किया गया है.
डुप्लीकेट कस्टम अनुमतियों का इस्तेमाल करने वाले ऐप्लिकेशन
कोई भी ऐप्लिकेशन अपनी पसंद के मुताबिक कोई भी कस्टम अनुमति तय कर सकता है. इसलिए, ऐसा हो सकता है कि कई ऐप्लिकेशन एक ही कस्टम अनुमति तय करें. उदाहरण के लिए, अगर दो ऐप्लिकेशन एक जैसी सुविधा देते हैं, तो हो सकता है कि वे अपनी कस्टम अनुमतियों के लिए एक ही लॉजिकल नाम का इस्तेमाल करें. ऐप्लिकेशन में, आम तौर पर इस्तेमाल होने वाली लाइब्रेरी या कोड के ऐसे उदाहरण भी शामिल किए जा सकते हैं जिनमें अनुमति की वही कस्टम परिभाषाएं शामिल हों.
Android 4.4 और उससे पहले के वर्शन में, उपयोगकर्ता किसी डिवाइस पर ऐसे कई ऐप्लिकेशन इंस्टॉल कर सकते थे. हालांकि, सिस्टम पहले इंस्टॉल किए गए ऐप्लिकेशन के हिसाब से सुरक्षा लेवल असाइन करता था.
Android 5.0 से, सिस्टम उन ऐप्लिकेशन के लिए एक नई पसंद के मुताबिक अनुमतियों पर यूनीक पाबंदी लागू करता है जिन्हें अलग-अलग पासकोड से साइन किया गया है. अब किसी डिवाइस पर सिर्फ़ एक ऐप्लिकेशन, पसंद के मुताबिक बनाई गई अनुमति तय कर सकता है. यह अनुमति, नाम से तय की जाती है. ऐसा तब तक नहीं किया जा सकता, जब तक कि अनुमति तय करने वाले दूसरे ऐप्लिकेशन को उसी पासकोड से साइन न किया गया हो. अगर उपयोगकर्ता, डुप्लीकेट कस्टम अनुमति वाले किसी ऐप्लिकेशन को इंस्टॉल करने की कोशिश करता है और उस पर उसी पासकोड से साइन नहीं किया गया है जिससे अनुमति देने वाले रेज़िडेंट ऐप्लिकेशन पर साइन किया गया है, तो सिस्टम ऐप्लिकेशन को इंस्टॉल करने से रोक देता है.
आपके ऐप्लिकेशन के लिए ध्यान रखने वाली बातें
Android 5.0 और उसके बाद के वर्शन में, ऐप्लिकेशन पहले की तरह ही अपनी पसंद के मुताबिक अनुमतियां तय कर सकते हैं. साथ ही, <uses-permission> प्रोसेस की मदद से, दूसरे ऐप्लिकेशन से अपनी पसंद के मुताबिक अनुमतियों का अनुरोध कर सकते हैं. हालांकि, Android 5.0 में बताई गई नई ज़रूरी शर्त के मुताबिक, आपको अपने ऐप्लिकेशन पर पड़ने वाले संभावित असर का ध्यान से आकलन करना चाहिए.
यहां कुछ बातों का ध्यान रखें:
- क्या आपके ऐप्लिकेशन के मेनिफ़ेस्ट में कोई
<permission>एलिमेंट शामिल है? अगर ऐसा है, तो क्या ये आपके ऐप्लिकेशन या सेवा के सही तरीके से काम करने के लिए ज़रूरी हैं? इसके अलावा, क्या सिस्टम की डिफ़ॉल्ट अनुमति का इस्तेमाल किया जा सकता है? - अगर आपके ऐप्लिकेशन में
<permission>एलिमेंट हैं, तो क्या आपको पता है कि ये एलिमेंट कहां से आए हैं? - क्या आपके मकसद से, दूसरे ऐप्लिकेशन
<uses-permission>के ज़रिए आपकी कस्टम अनुमतियों का अनुरोध कर सकते हैं? - क्या आपने अपने ऐप्लिकेशन में, बोयलरप्लेट या उदाहरण के तौर पर दिए गए ऐसे कोड का इस्तेमाल किया है जिसमें
<permission>एलिमेंट शामिल हैं? क्या अनुमति के लिए ये एलिमेंट ज़रूरी हैं? - क्या आपकी कस्टम अनुमतियों के नाम आसान हैं या वे सामान्य शब्दों पर आधारित हैं, जिन्हें दूसरे ऐप्लिकेशन भी इस्तेमाल कर सकते हैं?
नए इंस्टॉल और अपडेट
जैसा कि ऊपर बताया गया है, Android 4.4 या उससे पहले के वर्शन वाले डिवाइसों पर, आपके ऐप्लिकेशन के नए इंस्टॉल और अपडेट पर कोई असर नहीं पड़ेगा. साथ ही, ऐप्लिकेशन के काम करने के तरीके में भी कोई बदलाव नहीं होगा. Android 5.0 या इसके बाद के वर्शन वाले डिवाइसों पर नए इंस्टॉल और अपडेट के लिए, अगर सिस्टम में कोई ऐसी कस्टम अनुमति तय की गई है जो पहले से किसी मौजूदा ऐप्लिकेशन के लिए तय की गई है, तो सिस्टम आपके ऐप्लिकेशन को इंस्टॉल होने से रोक देता है.
Android 5.0 सिस्टम अपडेट के साथ मौजूदा इंस्टॉल
अगर आपका ऐप्लिकेशन कस्टम अनुमतियों का इस्तेमाल करता है और उसे बड़े पैमाने पर डिस्ट्रिब्यूट और इंस्टॉल किया गया है, तो हो सकता है कि उपयोगकर्ताओं के डिवाइसों को Android 5.0 पर अपडेट करने पर, उस पर असर पड़े. सिस्टम अपडेट इंस्टॉल होने के बाद, सिस्टम इंस्टॉल किए गए ऐप्लिकेशन की फिर से पुष्टि करता है. इसमें, उनकी कस्टम अनुमतियों की जांच भी शामिल है. अगर आपके ऐप्लिकेशन में ऐसी कस्टम अनुमति दी गई है जिसे पहले से ही किसी दूसरे ऐप्लिकेशन के लिए तय किया गया है और जिसकी पुष्टि हो चुकी है और आपके ऐप्लिकेशन को उसी पासकोड से साइन नहीं किया गया है जिससे दूसरे ऐप्लिकेशन को साइन किया गया है, तो सिस्टम आपके ऐप्लिकेशन को फिर से इंस्टॉल नहीं करता.
सुझाव
हमारा सुझाव है कि Android 5.0 या इसके बाद के वर्शन वाले डिवाइसों पर, आप तुरंत अपने ऐप्लिकेशन की जांच करें और ज़रूरी बदलाव करें. साथ ही, अपडेट किया गया वर्शन अपने उपयोगकर्ताओं के लिए जल्द से जल्द पब्लिश करें.
- अगर आपने अपने ऐप्लिकेशन में कस्टम अनुमतियों का इस्तेमाल किया है, तो उनके ऑरिजिन पर ध्यान दें
और देखें कि आपको उनकी ज़रूरत है या नहीं. अपने ऐप्लिकेशन से सभी
<permission>एलिमेंट हटाएं. ऐसा तब तक करें, जब तक आपको यह पक्का न हो जाए कि ये एलिमेंट आपके ऐप्लिकेशन के सही तरीके से काम करने के लिए ज़रूरी हैं. - जहां तक हो सके, अपनी कस्टम अनुमतियों को सिस्टम की डिफ़ॉल्ट अनुमतियों से बदलें.
- अगर आपके ऐप्लिकेशन को कस्टम अनुमतियों की ज़रूरत है, तो अपने ऐप्लिकेशन के लिए यूनीक कस्टम अनुमतियों का नाम बदलें. उदाहरण के लिए, उन्हें अपने ऐप्लिकेशन के पूरे पैकेज के नाम के साथ जोड़ें.
- अगर आपके पास ऐप्लिकेशन का ऐसा सुइट है जिस पर अलग-अलग कुंजियों से साइन किया गया है और ऐप्लिकेशन, पसंद के मुताबिक बनाई गई अनुमति की मदद से शेयर किए गए कॉम्पोनेंट को ऐक्सेस करते हैं, तो पक्का करें कि शेयर किए गए कॉम्पोनेंट में, पसंद के मुताबिक बनाई गई अनुमति सिर्फ़ एक बार तय की गई हो. शेयर किए गए कॉम्पोनेंट का इस्तेमाल करने वाले ऐप्लिकेशन को, अपनी पसंद के मुताबिक अनुमति तय नहीं करनी चाहिए. इसके बजाय, उन्हें
<uses-permission>प्रोसेस की मदद से ऐक्सेस का अनुरोध करना चाहिए. - अगर आपके पास ऐप्लिकेशन का ऐसा सुइट है जिसे एक ही पासकोड से साइन किया गया है, तो ज़रूरत के हिसाब से हर ऐप्लिकेशन में एक ही कस्टम अनुमति तय की जा सकती है. सिस्टम, ऐप्लिकेशन को सामान्य तरीके से इंस्टॉल करने की अनुमति देता है.
TLS/SSL के डिफ़ॉल्ट कॉन्फ़िगरेशन में बदलाव
Android 5.0 में, एचटीटीपीएस और अन्य टीएलएस/एसएसएल ट्रैफ़िक के लिए, ऐप्लिकेशन के इस्तेमाल किए जाने वाले डिफ़ॉल्ट टीएलएस/एसएसएल कॉन्फ़िगरेशन में बदलाव किए गए हैं:
- TLSv1.2 और TLSv1.1 प्रोटोकॉल अब चालू हैं,
- AES-GCM (AEAD) साइफ़र सुइट अब चालू हैं,
- MD5, 3DES, एक्सपोर्ट, और स्टैटिक कुंजी वाले ECDH साइफ़र सुइट अब बंद कर दिए गए हैं,
- अतिरिक्त सुरक्षा प्रोटोकॉल वाले साइफ़र सुइट (ECDHE और DHE) का इस्तेमाल करना बेहतर होता है.
इन बदलावों की वजह से, यहां बताए गए कुछ मामलों में एचटीटीपीएस या TLS/एसएसएल कनेक्टिविटी में रुकावट आ सकती है.
ध्यान दें कि Google Play services में मौजूद सुरक्षा से जुड़ी सेवा देने वाली कंपनी, पहले से ही Android 2.3 से लेकर Android के सभी वर्शन के लिए ये बदलाव उपलब्ध कराती है.
सर्वर, चालू किए गए किसी भी सिफर सुइट के साथ काम नहीं करता
उदाहरण के लिए, हो सकता है कि कोई सर्वर सिर्फ़ 3DES या MD5 सिफर सुइट के साथ काम करे. इस गड़बड़ी को ठीक करने का सबसे सही तरीका यह है कि आप सर्वर के कॉन्फ़िगरेशन को बेहतर बनाएं, ताकि ज़्यादा सुरक्षित और आधुनिक सिफर सुइट और प्रोटोकॉल इस्तेमाल किए जा सकें. आम तौर पर, TLSv1.2 और AES-GCM को चालू किया जाना चाहिए. साथ ही, फ़ॉरवर्ड सिक्योरिटी वाले साइफ़र सुइट (ECDHE, DHE) को चालू किया जाना चाहिए और उन्हें प्राथमिकता दी जानी चाहिए.
इसके अलावा, ऐप्लिकेशन में बदलाव करके, कस्टम SSLSocketFactory का इस्तेमाल करके, सर्वर से संपर्क किया जा सकता है. फ़ैक्ट्री को इस तरह से डिज़ाइन किया जाना चाहिए कि वह ऐसे SSLSocket इंस्टेंस बना सके जिनमें डिफ़ॉल्ट साइफ़र सुइट के साथ-साथ, सर्वर के लिए ज़रूरी कुछ साइफ़र सुइट भी चालू हों.
ऐप्लिकेशन, सर्वर से कनेक्ट करने के लिए इस्तेमाल किए जाने वाले साइफ़र सुइट के बारे में गलत अनुमान लगा रहा है
उदाहरण के लिए, कुछ ऐप्लिकेशन में कस्टम X509TrustManager होता है, जो काम नहीं करता, क्योंकि यह मानता है कि authType पैरामीटर RSA होना चाहिए, लेकिन उसे ECDHE_RSA या DHE_RSA मिलता है.
सर्वर, TLSv1.1, TLSv1.2 या नए TLS एक्सटेंशन के साथ काम नहीं करता
उदाहरण के लिए, किसी सर्वर के साथ टीएलएस/एसएसएल हैंडशेक गलत तरीके से अस्वीकार हो जाता है या रुक जाता है. इस गड़बड़ी को ठीक करने का सबसे सही तरीका यह है कि सर्वर को TLS/एसएसएल प्रोटोकॉल के मुताबिक अपग्रेड किया जाए. इससे सर्वर, इन नए प्रोटोकॉल के साथ नेगोशिएट कर पाएगा या TLSv1 या पुराने प्रोटोकॉल के साथ नेगोशिएट कर पाएगा. साथ ही, ऐसे TLS एक्सटेंशन को अनदेखा कर पाएगा जो उसे समझ नहीं आते. कुछ मामलों में, सर्वर पर TLSv1.1 और TLSv1.2 को बंद करने से, सर्वर सॉफ़्टवेयर के अपग्रेड होने तक, समस्या हल हो सकती है.
इसके अलावा, ऐप्लिकेशन में बदलाव करके, कस्टम SSLSocketFactory का इस्तेमाल करके, सर्वर से संपर्क किया जा सकता है. फ़ैक्ट्री को इस तरह से डिज़ाइन किया जाना चाहिए कि वह सिर्फ़ उन प्रोटोकॉल के साथ SSLSocket इंस्टेंस बना सके जो सर्वर पर सही तरीके से काम करते हैं.
मैनेज की जा रही प्रोफ़ाइलों के लिए सहायता
डिवाइस के एडमिन, किसी डिवाइस पर मैनेज की जा रही प्रोफ़ाइल जोड़ सकते हैं. इस प्रोफ़ाइल का मालिकाना हक एडमिन के पास होता है. इसलिए, एडमिन के पास मैनेज की जा रही प्रोफ़ाइल को कंट्रोल करने का अधिकार होता है. हालांकि, उपयोगकर्ता की निजी प्रोफ़ाइल और उसके स्टोरेज का कंट्रोल, उपयोगकर्ता के पास ही रहता है. इस बदलाव से, आपके मौजूदा ऐप्लिकेशन के व्यवहार पर इन तरीकों से असर पड़ सकता है.
इंटेंट मैनेज करना
डिवाइस के एडमिन, मैनेज की जा रही प्रोफ़ाइल से सिस्टम ऐप्लिकेशन के ऐक्सेस पर पाबंदी लगा सकते हैं. इस मामले में, अगर कोई ऐप्लिकेशन मैनेज की जा रही प्रोफ़ाइल से ऐसा इंटेंट ट्रिगर करता है जिसे आम तौर पर उस ऐप्लिकेशन से मैनेज किया जाता है और मैनेज की जा रही प्रोफ़ाइल पर इंटेंट के लिए कोई सही हैंडलर नहीं है, तो इंटेंट की वजह से अपवाद होता है. उदाहरण के लिए, डिवाइस एडमिन, मैनेज की जा रही प्रोफ़ाइल पर मौजूद ऐप्लिकेशन को सिस्टम के कैमरा ऐप्लिकेशन को ऐक्सेस करने से रोक सकता है. अगर आपका ऐप्लिकेशन मैनेज की जा रही प्रोफ़ाइल पर चल रहा है और MediaStore.ACTION_IMAGE_CAPTURE के लिए startActivityForResult() को कॉल करता है, लेकिन मैनेज की जा रही प्रोफ़ाइल पर ऐसा कोई ऐप्लिकेशन नहीं है जो इंटेंट को मैनेज कर सकता है, तो ActivityNotFoundException दिखता है.
ऐसा होने से रोकने के लिए, किसी भी इंटेंट को ट्रिगर करने से पहले यह देख लें कि उसके लिए कम से कम एक हैंडलर मौजूद हो. मान्य हैंडलर की जांच करने के लिए, Intent.resolveActivity() पर कॉल करें. आसानी से फ़ोटो लें: Camera ऐप्लिकेशन से फ़ोटो लें में, इसका उदाहरण देखा जा सकता है.
सभी प्रोफ़ाइलों के साथ फ़ाइलें शेयर करना
हर प्रोफ़ाइल का अपना फ़ाइल स्टोरेज होता है. फ़ाइल का यूआरआई, फ़ाइल स्टोरेज में किसी खास जगह को दिखाता है. इसका मतलब है कि एक प्रोफ़ाइल पर मान्य फ़ाइल का यूआरआई, दूसरी प्रोफ़ाइल पर मान्य नहीं होगा. आम तौर पर, यह किसी ऐप्लिकेशन के लिए समस्या नहीं होती. आम तौर पर, ऐप्लिकेशन सिर्फ़ अपनी बनाई गई फ़ाइलों को ऐक्सेस करता है. हालांकि, अगर कोई ऐप्लिकेशन किसी इंटेंट से फ़ाइल अटैच करता है, तो फ़ाइल का यूआरआई अटैच करना सुरक्षित नहीं है. ऐसा इसलिए, क्योंकि कुछ मामलों में इंटेंट को दूसरी प्रोफ़ाइल पर मैनेज किया जा सकता है. उदाहरण के लिए, डिवाइस एडमिन यह तय कर सकता है कि इमेज कैप्चर करने के इवेंट को निजी प्रोफ़ाइल पर मौजूद कैमरा ऐप्लिकेशन मैनेज करे. अगर मैनेज की जा रही प्रोफ़ाइल पर मौजूद किसी ऐप्लिकेशन ने इंटेंट ट्रिगर किया है, तो कैमरे को इमेज को ऐसी जगह पर सेव करना होगा जहां मैनेज की जा रही प्रोफ़ाइल के ऐप्लिकेशन उसे पढ़ सकें.
अगर आपको किसी ऐसी फ़ाइल को किसी ऐसे इंटेंट से अटैच करना है जो एक प्रोफ़ाइल से दूसरी प्रोफ़ाइल में जा सकती है, तो फ़ाइल के लिए कॉन्टेंट यूआरआई बनाएं और उसका इस्तेमाल करें. कॉन्टेंट यूआरआई की मदद से फ़ाइलें शेयर करने के बारे में ज़्यादा जानकारी के लिए, फ़ाइलें शेयर करना लेख पढ़ें.
उदाहरण के लिए, डिवाइस एडमिन, ACTION_IMAGE_CAPTURE को निजी प्रोफ़ाइल में कैमरे से मैनेज करने की अनुमति दे सकता है. फ़ायरिंग इंटेंट के EXTRA_OUTPUT में कॉन्टेंट का यूआरआई होना चाहिए. इससे यह पता चलता है कि फ़ोटो को कहां सेव करना है. कैमरा ऐप्लिकेशन, उस यूआरआई से तय की गई जगह पर इमेज को सेव कर सकता है. साथ ही, जिस ऐप्लिकेशन ने इंटेंट को ट्रिगर किया है वह उस फ़ाइल को पढ़ सकता है. भले ही, वह ऐप्लिकेशन किसी दूसरी प्रोफ़ाइल पर हो.
लॉकस्क्रीन विजेट की सुविधा हटा दी गई
Android 5.0 में लॉक स्क्रीन विजेट की सुविधा नहीं है. हालांकि, होम स्क्रीन पर विजेट इस्तेमाल किए जा सकते हैं.