Android 7.0 के व्यवहार में बदलाव

नई सुविधाओं और क्षमताओं के साथ-साथ, Android 7.0 में सिस्टम और एपीआई के काम करने के तरीके में कई तरह के बदलाव किए गए हैं. इस दस्तावेज़ में कुछ अहम बदलावों को हाइलाइट किया गया है, जिन्हें आपको अपने ऐप्लिकेशन में होने वाले बदलावों को समझना चाहिए.

अगर आपने Android के लिए पहले कोई ऐप्लिकेशन पब्लिश किया था, तो ध्यान रखें कि आपके ऐप्लिकेशन पर इन बदलावों का असर पड़ सकता है.

बैटरी और मेमोरी

Android 7.0 में सिस्टम के व्यवहार में बदलाव शामिल हैं, ताकि डिवाइसों की बैटरी लाइफ़ बेहतर हो सके और रैम के इस्तेमाल को कम किया जा सके. इन बदलावों से, आपके ऐप्लिकेशन के सिस्टम संसाधनों के ऐक्सेस पर असर पड़ सकता है. साथ ही, कुछ खास इंटेंट के ज़रिए आपके ऐप्लिकेशन के अन्य ऐप्लिकेशन के साथ इंटरैक्ट करने के तरीके पर भी असर पड़ सकता है.

बैटरी बचाएं (डोज़)

Doze मोड को Android 6.0 (एपीआई लेवल 23) में लॉन्च किया गया था. यह मोड, डिवाइस के सीपीयू और नेटवर्क गतिविधियों को रोककर, बैटरी लाइफ़ को बेहतर बनाता है. ऐसा तब होता है, जब उपयोगकर्ता डिवाइस को चार्जिंग से हटा देता है, उसे कहीं से भी इस्तेमाल नहीं करता, और उसकी स्क्रीन बंद होती है. Android 7.0 में, Doze मोड को और बेहतर बनाया गया है. इसमें डिवाइस के सीपीयू और नेटवर्क पर पाबंदियों का सबसेट लागू किया जाता है. हालांकि, यह ज़रूरी नहीं है कि डिवाइस कहीं से भी इस्तेमाल न किया जा रहा हो. उदाहरण के लिए, जब हैंडसेट उपयोगकर्ता की जेब में हो.

पहला डायग्राम. यह इलस्ट्रेशन में दिखाया गया है कि बैटरी लाइफ़ को बेहतर बनाने के लिए, Doze ने सिस्टम की गतिविधि से जुड़ी पहली पाबंदियां कैसे लागू कीं.

जब कोई डिवाइस बैटरी पावर पर होता है और उसकी स्क्रीन कुछ समय के लिए बंद रहती है, तो डिवाइस 'डोज़' में चला जाता है और पाबंदियों का पहला सबसेट लागू करता है: यह ऐप्लिकेशन नेटवर्क का ऐक्सेस बंद कर देता है और जॉब और सिंक को रोक देता है. यदि डिवाइस Doze में प्रवेश करने के बाद कुछ समय तक स्थिर रहता है, तो सिस् टम, PowerManager.WakeLock, AlarmManager अलार्म, GPS और वाई-फ़ाई स् कैन पर शेष डोज़ प्रतिबंधों को लागू करता है. भले ही, Doze मोड की कुछ या सभी पाबंदियां लागू हों, सिस्टम डिवाइस को कुछ समय के लिए चालू करता है, ताकि रखरखाव की गतिविधियां की जा सकें. इस दौरान, ऐप्लिकेशन को नेटवर्क ऐक्सेस करने की अनुमति मिलती है. साथ ही, वे ऐसे सभी काम कर सकते हैं जिन्हें पहले पूरा नहीं किया जा सका था या सिंक नहीं किया जा सका था.

दूसरी इमेज. इस इलस्ट्रेशन में दिखाया गया है कि डिवाइस के कुछ समय तक इस्तेमाल में न होने पर, Doze मोड कैसे सिस्टम की गतिविधि पर दूसरी लेवल की पाबंदियां लगाता है.

ध्यान दें कि स्क्रीन को चालू करने या डिवाइस को प्लग-इन करने पर, बैटरी बचाएं और डेटा प्रोसेस करने से जुड़ी इन पाबंदियों को हटा दें. इस अतिरिक्त व्यवहार से, आपके ऐप्लिकेशन को Android 6.0 (एपीआई लेवल 23) में पेश किए गए Doze मोड के पिछले वर्शन के हिसाब से अडजस्ट करने के सुझावों और सबसे सही तरीकों पर कोई असर नहीं पड़ता. इस बारे में Doze मोड और ऐप्लिकेशन के स्टैंडबाय मोड के लिए ऑप्टिमाइज़ करना में बताया गया है. आपको अब भी उन सुझावों का पालन करना चाहिए. जैसे, मैसेज भेजने और पाने के लिए Firebase Cloud Messaging (FCM) का इस्तेमाल करना. साथ ही, Doze मोड के नए वर्शन के हिसाब से अपडेट करने की योजना बनाना.

Project Svelte: बैकग्राउंड में ऑप्टिमाइज़ेशन

Android 7.0 में, तीन इम्प्लीसिट ब्रॉडकास्ट हटा दिए गए हैं. इससे, मेमोरी के इस्तेमाल और बिजली की खपत, दोनों को ऑप्टिमाइज़ करने में मदद मिलती है. यह बदलाव ज़रूरी है, क्योंकि इम्प्लीसिट ब्रॉडकास्ट अक्सर उन ऐप्लिकेशन को शुरू करते हैं जिन्होंने बैकग्राउंड में उन्हें सुनने के लिए रजिस्टर किया है. इन ब्रॉडकास्ट को हटाने से, डिवाइस की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव को काफ़ी फ़ायदा मिल सकता है.

मोबाइल डिवाइसों की कनेक्टिविटी में बार-बार बदलाव होता है, जैसे कि वाई-फ़ाई और मोबाइल डेटा के बीच आना-जाना. फ़िलहाल, ऐप्लिकेशन अपनी मेनिफ़ेस्ट फ़ाइल में इंप्लिसिट CONNECTIVITY_ACTION ब्रॉडकास्ट के लिए किसी रिसीवर को रजिस्टर करके कनेक्टिविटी में होने वाले बदलावों पर नज़र रख सकते हैं. इस ब्रॉडकास्ट को पाने के लिए कई ऐप्लिकेशन रजिस्टर करते हैं. इसलिए, नेटवर्क के एक बार स्विच होने पर, ये सभी ऐप्लिकेशन एक साथ चालू हो सकते हैं और ब्रॉडकास्ट को एक साथ प्रोसेस कर सकते हैं.

इसी तरह, Android के पिछले वर्शन में, ऐप्लिकेशन अन्य ऐप्लिकेशन से, ACTION_NEW_PICTURE और ACTION_NEW_VIDEO के इम्प्लीसिट ब्रॉडकास्ट पाने के लिए रजिस्टर कर सकते थे. जैसे, Camera. जब कोई उपयोगकर्ता कैमरा ऐप्लिकेशन से तस्वीर लेता है, तो ये ऐप्लिकेशन ब्रॉडकास्ट को प्रोसेस करने के लिए चालू हो जाते हैं.

इन समस्याओं को कम करने के लिए, Android 7.0 में ये ऑप्टिमाइज़ेशन लागू किए गए हैं:

• Android 7.0 (एपीआई लेवल 24) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को CONNECTIVITY_ACTION ब्रॉडकास्ट तब नहीं मिलते, जब वे मेनिफ़ेस्ट में अपने ब्रॉडकास्ट रिसीवर के बारे में बताते हैं. अगर ऐप्लिकेशन ने BroadcastReceiver को Context.registerReceiver() के साथ रजिस्टर किया है और वह कॉन्टेक्स्ट अब भी मान्य है, तो ऐप्लिकेशन को अब भी CONNECTIVITY_ACTION ब्रॉडकास्ट मिलते रहेंगे.
• सिस्टम अब ACTION_NEW_PICTURE या ACTION_NEW_VIDEO ब्रॉडकास्ट नहीं भेजता. इस ऑप्टिमाइज़ेशन का असर सभी ऐप्लिकेशन पर पड़ता है, न कि सिर्फ़ उन ऐप्लिकेशन पर जो Android 7.0 को टारगेट करते हैं.

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

Android 7.0 (एपीआई लेवल 24) में बैकग्राउंड ऑप्टिमाइज़ेशन और अपने ऐप्लिकेशन को अडैप्ट करने के तरीके के बारे में ज़्यादा जानने के लिए, बैकग्राउंड ऑप्टिमाइज़ेशन लेख पढ़ें.

अनुमतियों में बदलाव

Android 7.0 में अनुमतियों में ऐसे बदलाव किए गए हैं जिनका असर आपके ऐप्लिकेशन पर पड़ सकता है.

फ़ाइल सिस्टम की अनुमति में बदलाव

निजी फ़ाइलों की सुरक्षा को बेहतर बनाने के लिए, Android 7.0 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन की निजी डायरेक्ट्री के ऐक्सेस पर पाबंदी लगा दी गई है (0700). यह सेटिंग निजी फ़ाइलों का मेटाडेटा लीक होने से रोकती है, जैसे कि उनका साइज़ या मौजूदगी. अनुमति में हुए इस बदलाव के कई दुष्परिणाम हैं:

• अब मालिक को निजी फ़ाइलों की अनुमतियों में छूट नहीं देनी चाहिए. MODE_WORLD_READABLE और/या MODE_WORLD_WRITEABLE का इस्तेमाल करके, फ़ाइल शेयर करने की कोशिश करने पर SecurityException ट्रिगर होगा.

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

• पैकेज के डोमेन के बाहर के file:// यूआरआई पास करने पर, रिसीवर को ऐसा पाथ मिल सकता है जिसे ऐक्सेस नहीं किया जा सकता. इसलिए, file:// यूआरआई को पास करने की कोशिश करने पर, FileUriExposedException ट्रिगर होता है. हमारा सुझाव है कि FileProvider का इस्तेमाल करके, किसी निजी फ़ाइल का कॉन्टेंट शेयर करें.
• DownloadManager, निजी तौर पर सेव की गई फ़ाइलों को फ़ाइल के नाम के हिसाब से अब शेयर नहीं कर सकता. COLUMN_LOCAL_FILENAME को ऐक्सेस करते समय, लेगसी ऐप्लिकेशन के पास ऐसा पाथ हो सकता है जिसे ऐक्सेस नहीं किया जा सकता. Android 7.0 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन, COLUMN_LOCAL_FILENAME को ऐक्सेस करने की कोशिश करते समय SecurityException को ट्रिगर करते हैं. DownloadManager.Request.setDestinationInExternalFilesDir() या DownloadManager.Request.setDestinationInExternalPublicDir() का इस्तेमाल करके, डाउनलोड की जगह को सार्वजनिक जगह पर सेट करने वाले लेगसी ऐप्लिकेशन, अब भी COLUMN_LOCAL_FILENAME में मौजूद पाथ को ऐक्सेस कर सकते हैं. हालांकि, इस तरीके का इस्तेमाल करने का सुझाव नहीं दिया जाता. DownloadManager से सार्वजनिक की गई किसी फ़ाइल को ऐक्सेस करने का पसंदीदा तरीका ContentResolver.openFileDescriptor() का इस्तेमाल करना है.

ऐप्लिकेशन के बीच फ़ाइलें शेयर करना

Android 7.0 को टारगेट करने वाले ऐप्लिकेशन के लिए, Android फ़्रेमवर्क StrictMode एपीआई की नीति लागू करता है. इस नीति के तहत, आपके ऐप्लिकेशन से बाहर file:// यूआरआई को एक्सपोज़ करने पर पाबंदी है. अगर फ़ाइल यूआरआई वाला कोई इंटेंट आपके ऐप्लिकेशन से बाहर जाता है, तो ऐप्लिकेशन FileUriExposedException अपवाद के साथ काम नहीं करता.

एक ऐप्लिकेशन से दूसरे ऐप्लिकेशन में फ़ाइलें शेयर करने के लिए, आपको content:// यूआरआई भेजना होगा और यूआरआई पर कुछ समय के लिए ऐक्सेस की अनुमति देनी होगी. FileProvider क्लास का इस्तेमाल करके, यह अनुमति देने का सबसे आसान तरीका है. अनुमतियों और फ़ाइलें शेयर करने के बारे में ज़्यादा जानकारी के लिए, फ़ाइलें शेयर करना लेख पढ़ें.

सुलभता सुविधाओं में सुधार

Android 7.0 में ऐसे बदलाव किए गए हैं जिनसे कम या खराब दृष्टि वाले लोगों के लिए, प्लैटफ़ॉर्म को इस्तेमाल करना आसान हो सके. आम तौर पर, इन बदलावों के लिए आपके ऐप्लिकेशन के कोड में बदलाव करने की ज़रूरत नहीं होती. हालांकि, आपको इन सुविधाओं की समीक्षा करनी चाहिए और उपयोगकर्ता अनुभव पर पड़ने वाले संभावित असर का आकलन करने के लिए, उन्हें अपने ऐप्लिकेशन के साथ टेस्ट करना चाहिए.

स्क्रीन ज़ूम करने की सुविधा

Android 7.0 में, उपयोगकर्ताओं को डिसप्ले का साइज़ सेट करने की सुविधा मिलती है. इससे स्क्रीन पर मौजूद सभी एलिमेंट को बड़ा या छोटा किया जा सकता है. इससे, कम दिखने की समस्या वाले लोगों के लिए डिवाइस को इस्तेमाल करना आसान हो जाता है. उपयोगकर्ता, स्क्रीन को sw320dp से ज़्यादा नहीं ज़ूम कर सकते. यह Nexus 4 की स्क्रीन की चौड़ाई है, जो एक सामान्य मीडियम साइज़ के फ़ोन की चौड़ाई होती है.

तीसरी इमेज. दाईं ओर दी गई स्क्रीन पर, Android 7.0 सिस्टम इमेज वाले डिवाइस के डिसप्ले साइज़ को बढ़ाने का असर दिखाया गया है.

डिवाइस की डेंसिटी बदलने पर, सिस्टम इन तरीकों से चल रहे ऐप्लिकेशन को सूचना देता है:

• अगर कोई ऐप्लिकेशन एपीआई लेवल 23 या इससे पहले के लेवल को टारगेट करता है, तो सिस्टम उसकी सभी बैकग्राउंड प्रोसेस को अपने-आप बंद कर देता है. इसका मतलब यह है कि अगर कोई उपयोगकर्ता सेटिंग स्क्रीन खोलने के लिए किसी ऐसे ऐप्लिकेशन से दूर जाता है और डिसप्ले साइज़ की सेटिंग में बदलाव करता है, तो सिस्टम ऐप्लिकेशन को उसी तरह से बंद कर देता है जैसे कम मेमोरी वाली स्थिति में होता है. अगर ऐप्लिकेशन में कोई फ़ोरग्राउंड प्रोसेस है, तो सिस्टम उन प्रोसेस को कॉन्फ़िगरेशन में हुए बदलाव के बारे में सूचना देता है. इस बारे में रनटाइम में होने वाले बदलावों को मैनेज करना में बताया गया है. यह सूचना ठीक वैसी ही दी जाती है जैसे डिवाइस का ओरिएंटेशन बदलने पर दी जाती है.
• अगर कोई ऐप्लिकेशन Android 7.0 को टारगेट करता है, तो उसकी सभी प्रोसेस (फ़ोरग्राउंड और बैकग्राउंड) को कॉन्फ़िगरेशन में हुए बदलाव की सूचना दी जाती है. इस बारे में रनटाइम में होने वाले बदलावों को मैनेज करना में बताया गया है.

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

• अपने ऐप्लिकेशन को ऐसे डिवाइस पर टेस्ट करें जिसकी स्क्रीन की चौड़ाई sw320dp हो. साथ ही, पक्का करें कि ऐप्लिकेशन ठीक से काम कर रहा हो.
• जब डिवाइस कॉन्फ़िगरेशन में बदलाव होता है, तो घनत्व के हिसाब से कैश मेमोरी में सेव की गई जानकारी को अपडेट करें. जैसे, कैश मेमोरी में सेव किए गए बिटमैप या नेटवर्क से लोड किए गए संसाधन. ऐप्लिकेशन को रोके जाने के बाद, फिर से शुरू करने पर कॉन्फ़िगरेशन में हुए बदलावों की जांच करें.

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

• डाइमेंशन की जानकारी देने के लिए, px यूनिट का इस्तेमाल न करें. ऐसा इसलिए, क्योंकि ये स्क्रीन डेंसिटी के हिसाब से स्केल नहीं होतीं. इसके बजाय, डेंसिटी-इंडिपेंडेंट पिक्सल (dp) यूनिट वाले डाइमेंशन की जानकारी दें.

सेटअप विज़र्ड में विज़न सेटिंग

Android 7.0 में, वेलकम स्क्रीन पर विज़न सेटिंग शामिल होती हैं. यहां उपयोगकर्ता, नए डिवाइस पर ये सुलभता सेटिंग सेट अप कर सकते हैं: ज़ूम करने के लिए हाथ का जेस्चर, फ़ॉन्ट का साइज़, डिसप्ले का साइज़, और TalkBack. इस बदलाव से, स्क्रीन की अलग-अलग सेटिंग से जुड़े गड़बड़ियों को ज़्यादा आसानी से देखा जा सकता है. इस सुविधा के असर का आकलन करने के लिए, आपको इन सेटिंग के चालू होने पर अपने ऐप्लिकेशन की जांच करनी चाहिए. आपको ये सेटिंग, सेटिंग > सुलभता में मिलेंगी.

प्लैटफ़ॉर्म लाइब्रेरी से एनडीके (NDK) ऐप्लिकेशन लिंक करना

Android 7.0 से, सिस्टम ऐप्लिकेशन को डाइनैमिक तौर पर, NDK लाइब्रेरी के अलावा किसी दूसरी लाइब्रेरी से लिंक करने से रोकता है. इससे आपका ऐप्लिकेशन क्रैश हो सकता है. ऐप्लिकेशन के व्यवहार में हुए इस बदलाव का मकसद, प्लैटफ़ॉर्म के अपडेट और अलग-अलग डिवाइसों पर एक जैसा अनुभव देना है. ऐसा हो सकता है कि आपका कोड, निजी लाइब्रेरी के साथ लिंक न हो रहा हो. हालांकि, हो सकता है कि आपके ऐप्लिकेशन में तीसरे पक्ष की स्टैटिक लाइब्रेरी, ऐसा कर रही हो. इसलिए, सभी डेवलपर को यह पक्का करना चाहिए कि उनके ऐप्लिकेशन, Android 7.0 पर चलने वाले डिवाइसों पर क्रैश न हों. अगर आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल करता है, तो आपको सिर्फ़ सार्वजनिक NDK API का इस्तेमाल करना चाहिए.

आपका ऐप्लिकेशन, प्लैटफ़ॉर्म के निजी एपीआई को ऐक्सेस करने की कोशिश इन तीन तरीकों से कर सकता है:

• आपका ऐप्लिकेशन, सीधे तौर पर प्लैटफ़ॉर्म की निजी लाइब्रेरी को ऐक्सेस करता है. आपको अपने ऐप्लिकेशन को अपडेट करना चाहिए, ताकि उन लाइब्रेरी की कॉपी शामिल की जा सके या सार्वजनिक NDK API का इस्तेमाल किया जा सके.
• आपका ऐप्लिकेशन तीसरे पक्ष की ऐसी लाइब्रेरी का इस्तेमाल करता है जो निजी प्लैटफ़ॉर्म की लाइब्रेरी ऐक्सेस करती है. भले ही आपको पता हो कि आपका ऐप्लिकेशन, निजी लाइब्रेरी को सीधे तौर पर ऐक्सेस नहीं करता, फिर भी आपको इस स्थिति के लिए अपने ऐप्लिकेशन की जांच करनी चाहिए.
• आपका ऐप्लिकेशन एक ऐसी लाइब्रेरी का संदर्भ देता है जो इसके APK में शामिल नहीं है. उदाहरण के लिए, ऐसा तब हो सकता है, जब आपने अपनी खुद की Workspace कॉपी इस्तेमाल करने की कोशिश की हो, लेकिन उसे अपने ऐप्लिकेशन के APK के साथ बंडल करना भूल गए हों. यह ऐप्लिकेशन, Android प्लैटफ़ॉर्म के ऐसे वर्शन पर सामान्य रूप से काम कर सकता है जिनमें libcrypto.so शामिल हो. हालांकि, ऐप्लिकेशन, Android के उन वर्शन पर क्रैश हो सकता है जिनमें यह लाइब्रेरी शामिल नहीं है. जैसे, Android 6.0 और इसके बाद के वर्शन. इसे ठीक करने के लिए, पक्का करें कि आपने अपने APK के साथ, अपनी सभी ऐसी लाइब्रेरी को बंडल किया हो जो NDK से नहीं हैं.

ऐप्लिकेशन को ऐसी नेटिव लाइब्रेरी का इस्तेमाल नहीं करना चाहिए जो NDK में शामिल नहीं हैं. ऐसा इसलिए, क्योंकि Android के अलग-अलग वर्शन के बीच, इन लाइब्रेरी में बदलाव हो सकता है या इन्हें हटाया जा सकता है. OpenSSL से BoringSSL पर स्विच करना, इस तरह के बदलाव का एक उदाहरण है. साथ ही, NDK में शामिल नहीं की गई प्लैटफ़ॉर्म लाइब्रेरी के लिए, साथ काम करने से जुड़ी कोई ज़रूरी शर्त नहीं होती. इसलिए, अलग-अलग डिवाइसों पर, लाइब्रेरी के साथ काम करने की सुविधा अलग-अलग लेवल पर मिल सकती है.

इस पाबंदी का फ़िलहाल रिलीज़ किए गए ऐप्लिकेशन पर पड़ने वाले असर को कम करने के लिए, libandroid_runtime.so, libcutils.so, libcrypto.so, और libssl.so जैसी लाइब्रेरी के सेट को कुछ समय के लिए, Android 7.0 (एपीआई लेवल 24) पर ऐक्सेस किया जा सकता है. हालांकि, ऐसा सिर्फ़ उन ऐप्लिकेशन के लिए किया जा सकता है जो एपीआई लेवल 23 या उससे पहले के वर्शन को टारगेट करते हैं. अगर आपका ऐप्लिकेशन इनमें से किसी एक लाइब्रेरी को लोड करता है, तो लॉगकैट एक चेतावनी जनरेट करता है और टारगेट डिवाइस पर आपको सूचना देने के लिए एक टॉस्ट दिखता है. अगर आपको ये चेतावनियां दिखती हैं, तो आपको अपने ऐप्लिकेशन को अपडेट करना चाहिए. ऐसा करके, उन लाइब्रेरी की कॉपी शामिल की जा सकती है या सिर्फ़ सार्वजनिक NDK API का इस्तेमाल किया जा सकता है. आने वाले समय में Android प्लैटफ़ॉर्म के रिलीज़ होने पर, हो सकता है कि आप पूरी तरह से निजी लाइब्रेरी का इस्तेमाल न कर पाएं. साथ ही, आपका ऐप्लिकेशन क्रैश हो जाए.

जब सभी ऐप्लिकेशन किसी ऐसे एपीआई को कॉल करते हैं जो न तो सार्वजनिक होता है और न ही कुछ समय के लिए ऐक्सेस किया जा सकता है, तो वे रनटाइम की गड़बड़ी जनरेट करते हैं. इस वजह से, System.loadLibrary और dlopen(3), दोनों ही NULL दिखाते हैं. साथ ही, इससे आपका ऐप्लिकेशन क्रैश हो सकता है. आपको अपने ऐप्लिकेशन कोड की समीक्षा करनी चाहिए, ताकि निजी प्लैटफ़ॉर्म एपीआई का इस्तेमाल बंद किया जा सके. साथ ही, Android 7.0 (एपीआई लेवल 24) पर काम करने वाले डिवाइस या एमुलेटर का इस्तेमाल करके, अपने ऐप्लिकेशन की पूरी तरह से जांच की जा सके. अगर आपको यह पक्का नहीं है कि आपका ऐप्लिकेशन, निजी लाइब्रेरी का इस्तेमाल करता है या नहीं, तो रनटाइम की गड़बड़ी की पहचान करने के लिए लॉगकैट देखें.

नीचे दी गई टेबल में, किसी ऐप्लिकेशन के व्यवहार के बारे में बताया गया है. यह व्यवहार, निजी नेटिव लाइब्रेरी के इस्तेमाल और टारगेट एपीआई लेवल (android:targetSdkVersion) के आधार पर तय होता है.

देखें कि आपका ऐप्लिकेशन निजी लाइब्रेरी का इस्तेमाल करता है या नहीं

निजी लाइब्रेरी लोड करने से जुड़ी समस्याओं का पता लगाने में आपकी मदद करने के लिए, logcat एक चेतावनी या रनटाइम गड़बड़ी जनरेट कर सकता है. उदाहरण के लिए, अगर आपका ऐप्लिकेशन, एपीआई लेवल 23 या इससे पहले के वर्शन को टारगेट करता है और Android 7.0 पर चलने वाले डिवाइस पर किसी निजी लाइब्रेरी को ऐक्सेस करने की कोशिश करता है, तो आपको इस तरह की चेतावनी दिख सकती है:

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Logcat की इन चेतावनियों से पता चलता है कि कौनसी लाइब्रेरी, निजी प्लैटफ़ॉर्म एपीआई को ऐक्सेस करने की कोशिश कर रही है. हालांकि, इनसे आपका ऐप्लिकेशन क्रैश नहीं होगा. अगर ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करता है, तो logcat इस रनटाइम गड़बड़ी को जनरेट करता है और आपका ऐप्लिकेशन क्रैश हो सकता है:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

अगर आपका ऐप्लिकेशन तीसरे पक्ष की ऐसी लाइब्रेरी का इस्तेमाल करता है जो डाइनैमिक तरीके से निजी प्लैटफ़ॉर्म के एपीआई से लिंक होती हैं, तो आपको ये लॉगकैट आउटपुट भी दिख सकते हैं. Android 7.0DK में मौजूद रीडलफ़ टूल की मदद से, किसी दी गई .so फ़ाइल की डाइनैमिक रूप से शेयर की गई सभी लाइब्रेरी की सूची जनरेट की जा सकती है. इसके लिए, आपको यह निर्देश देना होगा:

aarch64-linux-android-readelf -dW libMyLibrary.so

अपना ऐप्लिकेशन अपडेट करें

इस तरह की गड़बड़ियों को ठीक करने और यह पक्का करने के लिए कि आने वाले समय में प्लैटफ़ॉर्म के अपडेट होने पर आपका ऐप्लिकेशन क्रैश न हो, यहां कुछ तरीके दिए गए हैं:

• अगर आपका ऐप्लिकेशन निजी प्लैटफ़ॉर्म लाइब्रेरी का इस्तेमाल करता है, तो आपको उसे अपडेट करना चाहिए, ताकि उन लाइब्रेरी की अपनी कॉपी शामिल की जा सके या सार्वजनिक NDK एपीआई का इस्तेमाल किया जा सके.
• अगर आपका ऐप्लिकेशन, निजी सिंबल ऐक्सेस करने वाली तीसरे पक्ष की लाइब्रेरी का इस्तेमाल करता है, तो लाइब्रेरी को अपडेट करने के लिए, लाइब्रेरी के लेखक से संपर्क करें.
• पक्का करें कि आपने अपने APK के साथ, NDK के अलावा सभी लाइब्रेरी को पैकेज किया हो.
• libandroid_runtime.so में मौजूद getJavaVM और getJNIEnv के बजाय, स्टैंडर्ड JNI फ़ंक्शन का इस्तेमाल करें:

  AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
  AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
  JavaVM::AttachCurrentThread from <jni.h>.
  

• libcutils.so से मिले निजी property_get सिंबल के बजाय __system_property_get का इस्तेमाल करें. ऐसा करने के लिए, __system_property_get का इस्तेमाल इन चीज़ों के साथ करें:

  #include <sys/system_properties.h>

  ध्यान दें: सिस्टम प्रॉपर्टी की उपलब्धता और कॉन्टेंट की जांच, सीटीएस के ज़रिए नहीं की जाती. इन प्रॉपर्टी का इस्तेमाल पूरी तरह से बंद करना ही बेहतर होगा.

• libcrypto.so से मिले SSL_ctrl सिंबल के लोकल वर्शन का इस्तेमाल करें. उदाहरण के लिए, आपको अपनी .so फ़ाइल में libcyrpto.a को स्टैटिक तौर पर लिंक करना चाहिए या BoringSSL/OpenSSL से libcrypto.so का डाइनैमिक तौर पर लिंक किया गया वर्शन शामिल करना चाहिए और उसे अपने APK में पैकेज करना चाहिए.

Android for Work

Android 7.0 में Android for Work को लक्षित करने वाले ऐप्लिकेशन के बदलाव शामिल हैं, जिनमें प्रमाणपत्र इंस्टॉल करने, पासवर्ड रीसेट करने, द्वितीयक उपयोगकर्ता प्रबंधन और डिवाइस पहचानकर्ता के ऐक्सेस के ऐक्सेस शामिल हैं. अगर आपने Android for Work के लिए ऐप्लिकेशन बनाए हैं, तो आपको इन बदलावों की समीक्षा करनी चाहिए और अपने ऐप्लिकेशन में इनके हिसाब से बदलाव करने चाहिए.

• डीपीसी इसे सेट करने से पहले, आपको डिलीगेट किया गया सर्टिफ़िकेट इंस्टॉलर इंस्टॉल करना होगा. Android 7.0 (एपीआई लेवल 24) को टारगेट करने वाले प्रोफ़ाइल और डिवाइस के मालिक, दोनों के ऐप्लिकेशन के लिए, डिवाइस नीति कंट्रोलर (डीपीसी) के DevicePolicyManager.setCertInstallerPackage() को कॉल करने से पहले, आपको डिलीगेट किया गया सर्टिफ़िकेट इंस्टॉलर इंस्टॉल करना चाहिए. अगर इंस्टॉलर पहले से इंस्टॉल नहीं है, तो सिस्टम एक IllegalArgumentException दिखाता है.
• डिवाइस के एडमिन के लिए पासवर्ड रीसेट करने से जुड़ी पाबंदियां, अब प्रोफ़ाइल के मालिकों पर भी लागू होंगी. डिवाइस के एडमिन अब पासवर्ड मिटाने या पहले से सेट किए गए पासवर्ड बदलने के लिए DevicePolicyManager.resetPassword() का इस्तेमाल नहीं कर सकते हैं. डिवाइस के एडमिन अब भी पासवर्ड सेट कर सकते हैं, लेकिन डिवाइस में कोई पासवर्ड, पिन या पैटर्न न होने पर ही ऐसा किया जा सकता है.
• डिवाइस और प्रोफ़ाइल के मालिक, पाबंदियां सेट होने के बावजूद खाते मैनेज कर सकते हैं. डिवाइस के मालिक और प्रोफ़ाइल के मालिक, Account Management API को कॉल कर सकते हैं. ऐसा तब भी किया जा सकता है, जब DISALLOW_MODIFY_ACCOUNTS उपयोगकर्ता पर पाबंदियां लगी हों.
• डिवाइस के मालिक, दूसरे उपयोगकर्ताओं को आसानी से मैनेज कर सकते हैं. जब कोई डिवाइस, मालिक वाले मोड में चल रहा होता है, तो DISALLOW_ADD_USER की पाबंदी अपने-आप सेट हो जाती है. इससे उपयोगकर्ता, मैनेज नहीं किए जा सकने वाले सेकंडरी उपयोगकर्ताओं को नहीं बना पाते. इसके अलावा, CreateUser() और createAndInitializeUser() तरीके अब काम नहीं करते. इनकी जगह, अब DevicePolicyManager.createAndManageUser() तरीका इस्तेमाल किया जा सकता है.
• डिवाइस के मालिक, डिवाइस आइडेंटिफ़ायर ऐक्सेस कर सकते हैं. डिवाइस का मालिक, DevicePolicyManager.getWifiMacAddress() का इस्तेमाल करके, डिवाइस के वाई-फ़ाई के एमएसी (मैक) पते को ऐक्सेस कर सकता है. अगर डिवाइस पर वाई-फ़ाई कभी चालू नहीं किया गया है, तो यह तरीका null वैल्यू दिखाता है.
• वर्क मोड की सेटिंग से, वर्क ऐप्लिकेशन के ऐक्सेस को कंट्रोल किया जा सकता है. वर्क मोड बंद होने पर, सिस्टम लॉन्चर में ऑफ़िस के काम से जुड़े ऐप्लिकेशन धूसर रंग में दिखते हैं. इससे पता चलता है कि वे ऐप्लिकेशन उपलब्ध नहीं हैं. वर्क मोड को फिर से चालू करने पर, डिवाइस सामान्य रूप से काम करना शुरू कर देता है.
• जब किसी ऐसी PKCS #12 फ़ाइल को इंस्टॉल किया जाता है जिसमें क्लाइंट सर्टिफ़िकेट की चेन और सेटिंग यूज़र इंटरफ़ेस (यूआई) से जुड़ी निजी कुंजी होती है, तो उस चेन में सीए सर्टिफ़िकेट को भरोसेमंद क्रेडेंशियल के स्टोरेज में इंस्टॉल नहीं किया जाता. जब ऐप्लिकेशन, क्लाइंट सर्टिफ़िकेट चेन को वापस पाने की कोशिश करते हैं, तो KeyChain.getCertificateChain() के नतीजे पर इसका कोई असर नहीं पड़ता. अगर ज़रूरी हो, तो CA सर्टिफ़िकेट को सेटिंग यूज़र इंटरफ़ेस (यूआई) के ज़रिए, भरोसेमंद क्रेडेंशियल स्टोरेज में अलग से इंस्टॉल करना चाहिए. इसे .crt या .cer फ़ाइल एक्सटेंशन के तहत, DER कोड में बदले गए फ़ॉर्मैट के साथ इंस्टॉल किया जाना चाहिए.
• Android 7.0 से, फ़िंगरप्रिंट रजिस्टर करने और स्टोरेज को हर उपयोगकर्ता के हिसाब से मैनेज किया जाता है. अगर प्रोफ़ाइल के मालिक का डिवाइस नीति क्लाइंट (डीपीसी), Android 7.0 (एपीआई लेवल 24) पर चलने वाले डिवाइस पर एपीआई लेवल 23 (या इससे पहले के वर्शन) को टारगेट करता है, तो उपयोगकर्ता अब भी डिवाइस पर फ़िंगरप्रिंट सेट कर सकता है. हालांकि, वर्क ऐप्लिकेशन डिवाइस के फ़िंगरप्रिंट को ऐक्सेस नहीं कर सकते. जब डीपीसी, एपीआई लेवल 24 और उसके बाद के वर्शन को टारगेट करता है, तो उपयोगकर्ता सेटिंग > सुरक्षा > वर्क प्रोफ़ाइल की सुरक्षा पर जाकर, खास तौर पर वर्क प्रोफ़ाइल के लिए फ़िंगरप्रिंट सेट कर सकता है.
• DevicePolicyManager.getStorageEncryptionStatus() से एन्क्रिप्शन की नई स्थिति ENCRYPTION_STATUS_ACTIVE_PER_USER दिखती है. इससे पता चलता है कि एन्क्रिप्शन चालू है और एन्क्रिप्शन कुंजी, उपयोगकर्ता से जुड़ी है. नया स्टेटस सिर्फ़ तब दिखता है, जब डीपीसी, एपीआई लेवल 24 और उसके बाद के लेवल को टारगेट करता हो. पहले के एपीआई लेवल को टारगेट करने वाले ऐप्लिकेशन के लिए, ENCRYPTION_STATUS_ACTIVE दिखाया जाता है, भले ही एन्क्रिप्शन कुंजी उपयोगकर्ता या प्रोफ़ाइल के लिए खास हो.
• Android 7.0 में, कई ऐसे तरीके हैं जिनका आम तौर पर पूरे डिवाइस पर असर पड़ता है. हालांकि, अगर डिवाइस पर वर्क प्रोफ़ाइल इंस्टॉल है और उस पर अलग से वर्क चैलेंज है, तो ये तरीके अलग तरह से काम करते हैं. पूरे डिवाइस पर असर डालने के बजाय, ये तरीके सिर्फ़ वर्क प्रोफ़ाइल पर लागू होते हैं. (ऐसे तरीकों की पूरी सूची, DevicePolicyManager.getParentProfileInstance() दस्तावेज़ में दी गई है.) उदाहरण के लिए, DevicePolicyManager.lockNow() पूरे डिवाइस को लॉक करने के बजाय, सिर्फ़ वर्क प्रोफ़ाइल को लॉक करता है. इनमें से किसी भी तरीके के लिए, DevicePolicyManager के पैरंट इंस्टेंस पर तरीका कॉल करके, पुराना व्यवहार पाया जा सकता है. इस पैरंट को पाने के लिए, DevicePolicyManager.getParentProfileInstance() को कॉल करें. उदाहरण के लिए, अगर पैरंट इंस्टेंस के lockNow() तरीके को कॉल किया जाता है, तो पूरा डिवाइस लॉक हो जाता है.

टिप्पणियों का रखरखाव

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

• VISIBILITY_BUILD: इसे सिर्फ़ बिल्ड के समय दिखाया जाना चाहिए.
• VISIBILITY_SYSTEM: रनटाइम के दौरान दिखने के लिए, लेकिन सिर्फ़ उस सिस्टम के लिए.

अगर आपके ऐप्लिकेशन ने इस व्यवहार पर भरोसा किया है, तो एनोटेशन के लिए निजी डेटा के रखरखाव की ऐसी नीति जोड़ें जो रनटाइम के दौरान उपलब्ध हो. इसके लिए, @Retention(RetentionPolicy.RUNTIME) का इस्तेमाल करें.

TLS/एसएसएल के डिफ़ॉल्ट कॉन्फ़िगरेशन में बदलाव

Android 7.0, डिफ़ॉल्ट TLS/SSL कॉन्फ़िगरेशन में ये बदलाव करता है. ऐप्लिकेशन, एचटीटीपीएस और अन्य TLS/SSL ट्रैफ़िक के लिए इसका इस्तेमाल करते हैं:

• RC4 साइफ़र सुइट अब बंद कर दिए गए हैं.
• CHACHA20-POLY1305 साइफ़र सुइट अब चालू हैं.

RC4 को डिफ़ॉल्ट रूप से बंद करने पर, एचटीटीपीएस या TLS/एसएसएल कनेक्शन में रुकावट आ सकती है. ऐसा तब होता है, जब सर्वर नए साइफ़र सुइट के साथ काम नहीं करता. इस गड़बड़ी को ठीक करने का सबसे सही तरीका यह है कि सर्वर के कॉन्फ़िगरेशन को बेहतर बनाया जाए, ताकि ज़्यादा सुरक्षित और आधुनिक सिफर सुइट और प्रोटोकॉल इस्तेमाल किए जा सकें. आम तौर पर, TLSv1.2 और AES-GCM को चालू किया जाना चाहिए. साथ ही, फ़ॉरवर्ड सिक्योरिटी साइफ़र सुइट (ECDHE) को चालू और प्राथमिकता दी जानी चाहिए.

इसके अलावा, ऐप्लिकेशन में बदलाव करके, सर्वर से संपर्क करने के लिए कस्टम SSLSocketFactory का इस्तेमाल किया जा सकता है. फ़ैक्ट्री को इस तरह डिज़ाइन किया जाना चाहिए कि वह SSLSocket के ऐसे इंस्टेंस बना सके जिनमें डिफ़ॉल्ट सिफर सुइट के साथ-साथ, सर्वर के लिए ज़रूरी कुछ सिफर सुइट भी चालू हों.

ध्यान दें: ये बदलाव WebView पर लागू नहीं होते.

Android 7.0 को टारगेट करने वाले ऐप्लिकेशन

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

सीरियलाइज़ेशन में बदलाव

Android 7.0 (एपीआई लेवल 24) ने डिफ़ॉल्ट सीरियलVersionUID को कैलकुलेट करने के दौरान, एक गड़बड़ी ठीक की है, जहां यह स्पेसिफ़िकेशन के मुताबिक नहीं था.

Serializable को लागू करने वाली और serialVersionUID फ़ील्ड की जानकारी साफ़ तौर पर न देने वाली क्लास के डिफ़ॉल्ट serialVersionUID में बदलाव दिख सकता है. इससे, किसी क्लास के ऐसे इंस्टेंस को डिससिरियलाइज़ करने की कोशिश करते समय अपवाद दिखेगा जिन्हें किसी पुराने वर्शन पर सिरियलाइज़ किया गया था या किसी ऐसे ऐप्लिकेशन ने सिरियलाइज़ किया था जो किसी पुराने वर्शन को टारगेट करता है. गड़बड़ी का मैसेज कुछ ऐसा दिखेगा:

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

इन समस्याओं को ठीक करने के लिए, जिन कैटगरी पर असर पड़ा है उनमें serialVersionUID फ़ील्ड जोड़ना ज़रूरी है.साथ ही, इस फ़ील्ड में गड़बड़ी के मैसेज में दी गई stream classdesc serialVersionUID वैल्यू डालनी होगी. उदाहरण के लिए, इस मामले में 1234. यह बदलाव, सिलसिलेवार तरीके से डेटा को स्टोर करने का कोड लिखने के लिए, सबसे सही तरीकों के सभी सुझावों का पालन करता है. साथ ही, यह Android के सभी वर्शन पर काम करेगा.

जिस गड़बड़ी को ठीक किया गया था वह स्टैटिक शुरू करने के तरीकों की मौजूदगी से जुड़ी थी, जैसे कि <clinit>. स्पेसिफ़िकेशन के मुताबिक, क्लास में स्टैटिक शुरू करने वाले तरीके की मौजूदगी या अनुपस्थिति का असर, उस क्लास के लिए कैलकुलेट किए गए डिफ़ॉल्ट serialVersionUID पर पड़ेगा. गड़बड़ी ठीक करने से पहले, अगर क्लास में कोई स्टैटिक शुरू नहीं होता, तो कैलकुलेशन में सुपर क्लास की जांच भी की जाती है.

साफ़ तौर पर बता दें कि इस बदलाव का असर, एपीआई लेवल 23 या इससे पहले के लेवल को टारगेट करने वाले ऐप्लिकेशन, serialVersionUID फ़ील्ड वाली क्लास या स्टैटिक शुरू करने वाले तरीके वाली क्लास पर नहीं पड़ेगा.

अन्य अहम बातें

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

  आपको अपने ऐप्लिकेशन की जांच करनी चाहिए, ताकि यह पक्का किया जा सके कि ऐसा न हो. ऐसा करने के लिए, DDMS की मदद से ऐप्लिकेशन को मैन्युअल तरीके से बंद करते समय, ऐप्लिकेशन को क्रैश कराएं.

  Android 7.0 (एपीआई लेवल 24) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन, डिसप्ले की पिक्सल डेंसिटी में बदलाव होने पर अपने-आप बंद नहीं होते. हालांकि, हो सकता है कि वे कॉन्फ़िगरेशन में होने वाले बदलावों का ठीक से जवाब न दें.

• Android 7.0 पर काम करने वाले ऐप्लिकेशन, कॉन्फ़िगरेशन में होने वाले बदलावों को आसानी से मैनेज कर सकते हैं. साथ ही, उन्हें फिर से शुरू करने पर क्रैश नहीं होना चाहिए. फ़ॉन्ट साइज़ (सेटिंग > डिसप्ले > फ़ॉन्ट साइज़) बदलकर, ऐप्लिकेशन के व्यवहार की पुष्टि की जा सकती है. इसके बाद, हाल ही में इस्तेमाल किए गए ऐप्लिकेशन में जाकर, ऐप्लिकेशन को वापस लाया जा सकता है.
• Android के पिछले वर्शन में कोई गड़बड़ी होने की वजह से, सिस्टम ने मुख्य थ्रेड पर टीसीपी सॉकेट में मैसेज को सख्त मोड के उल्लंघन के तौर पर फ़्लैग नहीं किया. Android 7.0 इस गड़बड़ी को ठीक कर देता है. ऐसा करने वाले ऐप्लिकेशन अब android.os.NetworkOnMainThreadException दिखाते हैं. आम तौर पर, मुख्य थ्रेड पर नेटवर्क ऑपरेशन करना एक बुरा आइडिया है. ऐसा इसलिए, क्योंकि इन ऑपरेशन के लिए आम तौर पर ज़्यादा इंतज़ार करना पड़ता है. इससे ANR और रुकावट की समस्याएं आती हैं.
• Debug.startMethodTracing() फ़ैमिली के तरीके अब डिफ़ॉल्ट रूप से, एसडी कार्ड के सबसे ऊपर के लेवल के बजाय, शेयर किए गए स्टोरेज में आपके पैकेज की डायरेक्ट्री में आउटपुट सेव करते हैं. इसका मतलब है कि अब इन एपीआई का इस्तेमाल करने के लिए, ऐप्लिकेशन को WRITE_EXTERNAL_STORAGE अनुमति का अनुरोध करने की ज़रूरत नहीं होगी.
• कई प्लैटफ़ॉर्म एपीआई ने अब Binder लेन-देन में भेजे जा रहे बड़े पेलोड की जांच करना शुरू कर दिया है. सिस्टम अब TransactionTooLargeExceptions को RuntimeExceptions के तौर पर फिर से रिकॉर्ड कर रहा है. वह इन्हें बिना किसी रुकावट के लॉग या बंद कर रहा है. एक सामान्य उदाहरण, Activity.onSaveInstanceState() में बहुत ज़्यादा डेटा स्टोर करना है. इससे, जब आपका ऐप्लिकेशन Android 7.0 को टारगेट करता है, तो ActivityThread.StopInfo से RuntimeException दिखता है.
• अगर कोई ऐप्लिकेशन, View में Runnable टास्क पोस्ट करता है और View विंडो के साथ अटैच नहीं है, तो सिस्टम Runnable टास्क को View की सूची में जोड़ देता है. वहीं, Runnable टास्क तब तक लागू नहीं होता, जब तक View, विंडो से अटैच नहीं हो जाता. इससे यहां दी गई गड़बड़ियां ठीक हो जाती हैं:
  • अगर कोई ऐप्लिकेशन, अपनी पसंद की विंडो के यूज़र इंटरफ़ेस (यूआई) थ्रेड के बजाय किसी दूसरे थ्रेड से View पर पोस्ट करता है, तो हो सकता है कि Runnable गलत थ्रेड पर चले.
  • अगर Runnable टास्क, लूपर थ्रेड के बजाय किसी दूसरे थ्रेड से पोस्ट किया गया था, तो ऐप्लिकेशन Runnable टास्क दिखा सकता है.
• अगर Android 7.0 पर, DELETE_PACKAGES अनुमति वाले किसी ऐप्लिकेशन ने किसी पैकेज को मिटाने की कोशिश की, लेकिन उस पैकेज को किसी दूसरे ऐप्लिकेशन ने इंस्टॉल किया था, तो सिस्टम को उपयोगकर्ता की पुष्टि की ज़रूरत होगी. इस स्थिति में, ऐप्लिकेशन को PackageInstaller.uninstall() को कॉल करने पर, रिटर्न स्टेटस के तौर पर STATUS_PENDING_USER_ACTION दिखना चाहिए.
• Crypto नाम का JCA प्रोवाइडर अब काम नहीं करता, क्योंकि इसका एकमात्र एल्गोरिदम, SHA1PRNG, क्रिप्टोग्राफ़िक तौर पर कमज़ोर है. ऐप्लिकेशन अब SHA1PRNG का इस्तेमाल करके, कुंजियों को (असुरक्षित तरीके से) जनरेट नहीं कर सकते. ऐसा इसलिए है, क्योंकि यह सेवा अब उपलब्ध नहीं है. ज़्यादा जानकारी के लिए, ब्लॉग पोस्ट Android N में सुरक्षा "क्रिप्ट" प्रोवाइडर बंद कर दिया गया है देखें.