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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Android 7.0 (एपीआई लेवल 24) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को CONNECTIVITY_ACTION ब्रॉडकास्ट करता है, अगर वे मेनिफ़ेस्ट में अपने ब्रॉडकास्ट रिसीवर की जानकारी दें. ऐप्लिकेशन अब भी रजिस्टर होने पर CONNECTIVITY_ACTION ब्रॉडकास्ट पाएं Context.registerReceiver() के साथ उसकी BroadcastReceiver और वह संदर्भ अब भी मान्य है.
• सिस्टम अब 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 या इसके बाद वाला वर्शन, SecurityException को ट्रिगर करता है, जब ऐक्सेस करने की कोशिश की जा रही है COLUMN_LOCAL_FILENAME. वे लेगसी ऐप्लिकेशन जो इसके द्वारा डाउनलोड स्थान को किसी सार्वजनिक स्थान पर सेट करते हैं इसका उपयोग कर रहा है DownloadManager.Request.setDestinationInExternalFilesDir() या DownloadManager.Request.setDestinationInExternalPublicDir() अब भी पाथ को ऐक्सेस कर सकता है हालांकि, COLUMN_LOCAL_FILENAME के लिए यह विधि की सलाह नहीं दी जाती है. फ़ाइल को ऐक्सेस करने का पसंदीदा तरीका DownloadManager के ज़रिए खतरा हो सकता है ContentResolver.openFileDescriptor().

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

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

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

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

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

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

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

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

डिवाइस की सघनता में बदलाव होने पर, सिस्टम, इन तरीकों से मदद पाएं:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निजी लाइब्रेरी लोड करने में आने वाली समस्याओं का पता लगाने में आपकी मदद करने के लिए, 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 चेतावनियां आपको बताती हैं कि कौनसी लाइब्रेरी Private Platform API का इस्तेमाल करें, लेकिन इससे आपका ऐप्लिकेशन क्रैश नहीं होगा. अगर ऐप्लिकेशन एपीआई लेवल 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

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

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

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

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

• निजी property_get के बजाय __system_property_get का इस्तेमाल करें libcutils.so से मिला चिह्न. ऐसा करने के लिए, __system_property_get का उपयोग करें जिसमें ये शामिल हैं:

  #include <sys/system_properties.h>
  

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

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

Android for Work

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

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

• आरसी4 साइफ़र सुइट को अब बंद कर दिया गया है.
• CHACHA20-POLY1305 साइफ़र सुइट अब चालू हैं.

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

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

ध्यान दें: ये बदलाव WebView से जुड़े नहीं हैं.

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

व्यवहार में ये बदलाव खास तौर पर, टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) वाले ऐप्लिकेशन पर लागू होते हैं Android 7.0 (एपीआई लेवल 24) या उसके बाद का वर्शन. Android 7.0 के हिसाब से कंपाइल किए जाने वाले ऐप्लिकेशन, या targetSdkVersion को Android 7.0 या उसके बाद वाले वर्शन पर सेट करना ज़रूरी है जहां भी लागू हो, वे इस तरह की गतिविधियों को ठीक से पूरा करने में मदद करें.

क्रम से लगाने के तरीके में बदलाव

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

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

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

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

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

हम साफ़ तौर पर बता रहे हैं कि इस बदलाव का असर उन ऐप्लिकेशन पर नहीं पड़ेगा जो एपीआई लेवल 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(), जिसकी वजह से ActivityThread.StopInfo Android 7.0 को टारगेट करने पर RuntimeException.
• अगर कोई ऐप्लिकेशन, View पर Runnable टास्क पोस्ट करता है और View किसी विंडो से नहीं जुड़ा होता है, तो सिस्टम Runnable टास्क को View के साथ सूची में लगाता है; Runnable टास्क तब तक लागू नहीं होता है, जब तक View अटैच किया गया है विंडो में ले जाएं. इससे यहां दी गई गड़बड़ियां ठीक हो जाती हैं:
  • अगर कोई ऐप्लिकेशन, बताए गए थ्रेड के बजाय किसी दूसरी थ्रेड से View पर पोस्ट किया गया हो विंडो में सेट किया गया यूज़र इंटरफ़ेस (यूआई) थ्रेड है, तो हो सकता है कि Runnable गलत थ्रेड पर चले.
  • अगर Runnable टास्क को इसके अलावा किसी दूसरी थ्रेड से पोस्ट किया गया हो एक लूपर थ्रेड है, तो ऐप्लिकेशन Runnable टास्क दिखा सकता है.
• अगर Android 7.0 पर मौजूद किसी ऐप्लिकेशन DELETE_PACKAGES अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अनुमति किसी पैकेज को हटाने की कोशिश करती है, लेकिन किसी और ऐप्लिकेशन ने उस पैकेज को इंस्टॉल किया था, सिस्टम को चलाने के लिए उपयोगकर्ता की पुष्टि करना ज़रूरी है. इस स्थिति में, ऐप्लिकेशन को STATUS_PENDING_USER_ACTION अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है को रिटर्न स्थिति के तौर पर तब माना जाता है, जब वे PackageInstaller.uninstall().
• JCA की सेवा देने वाली क्रिप्टो नाम की सेवा अब काम नहीं करती. इसकी वजह यह है कि सिर्फ़ एल्गोरिदम, SHA1PRNG, क्रिप्टोग्राफ़िक तौर पर कमज़ोर है. ऐप्लिकेशन अब इस्तेमाल नहीं कर पाएंगे SHA1PRNG (असुरक्षित रूप से) कुंजियां प्राप्त करने के लिए, क्योंकि यह कंपनी अब उपलब्ध हैं. ज़्यादा जानकारी के लिए, यह ब्लॉग देखें पोस्ट सुरक्षा "क्रिप्टो" Android में कंपनी बंद कर दी गई है नहीं.