ऐप्लिकेशन के व्यवहार में बदलाव: सभी ऐप्लिकेशन

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

सिर्फ़ एपीआई लेवल 28 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन पर असर डालने वाले बदलावों के बारे में जानने के लिए, ऐप्लिकेशन के व्यवहार में हुए बदलाव: एपीआई लेवल 28 और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन लेख पढ़ें.

पावर मैनेजमेंट

Android 9 में नई सुविधाएं जोड़ी गई हैं, ताकि डिवाइस की बैटरी मैनेज करने की सुविधा को बेहतर बनाया जा सके. Android 9 से पहले मौजूद सुविधाओं के साथ-साथ, इन बदलावों से यह पक्का करने में मदद मिलती है कि सिस्टम के संसाधन उन ऐप्लिकेशन के लिए उपलब्ध कराए जाएं जिनके लिए उनकी ज़्यादा ज़रूरत है.

ज़्यादा जानकारी के लिए, पावर मैनेजमेंट लेख पढ़ें.

निजता से जुड़े बदलाव

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

इन बदलावों का असर, Android 9 पर चलने वाले सभी ऐप्लिकेशन पर पड़ेगा. भले ही, SDK टूल के टारगेट किए गए वर्शन का कोई भी हो.

बैकग्राउंड में सेंसर का सीमित ऐक्सेस

Android 9, बैकग्राउंड ऐप्लिकेशन के लिए उपयोगकर्ता के इनपुट और सेंसर डेटा को ऐक्सेस करने की सुविधा को सीमित करता है. अगर आपका ऐप्लिकेशन, Android 9 वाले डिवाइस पर बैकग्राउंड में चल रहा है, तो सिस्टम आपके ऐप्लिकेशन पर ये पाबंदियां लगाता है:

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

अगर आपके ऐप्लिकेशन को Android 9 पर चलने वाले डिवाइसों पर सेंसर इवेंट का पता लगाना है, तो फ़ोरग्राउंड सेवा का इस्तेमाल करें.

कॉल लॉग के ऐक्सेस पर पाबंदी लगी है

Android 9 में, CALL_LOG अनुमति वाला ग्रुप जोड़ा गया है. साथ ही, READ_CALL_LOG, WRITE_CALL_LOG, और PROCESS_OUTGOING_CALLS अनुमतियों को इस ग्रुप में ले जाया गया है. Android के पिछले वर्शन में, ये अनुमतियां PHONE अनुमति ग्रुप में होती थीं.

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

अगर आपके ऐप्लिकेशन को कॉल लॉग ऐक्सेस करने या आउटगोइंग कॉल को प्रोसेस करने की ज़रूरत है, तो आपको CALL_LOG अनुमति ग्रुप से साफ़ तौर पर इन अनुमतियों का अनुरोध करना होगा. ऐसा न करने पर, SecurityException दिखता है.

फ़ोन नंबर के ऐक्सेस पर पाबंदी लगी है

Android 9 पर काम करने वाले ऐप्लिकेशन, पहले READ_CALL_LOG की अनुमति लिए बिना, फ़ोन नंबर या फ़ोन की स्थिति नहीं पढ़ सकते. साथ ही, ऐप्लिकेशन के इस्तेमाल के उदाहरणों के लिए ज़रूरी अन्य अनुमतियां भी लेनी होंगी.

इनकमिंग और आउटगोइंग कॉल से जुड़े फ़ोन नंबर, फ़ोन की स्थिति के ब्रॉडकास्ट में दिखते हैं. जैसे, इनकमिंग और आउटगोइंग कॉल के लिए. इन्हें PhoneStateListener क्लास से ऐक्सेस किया जा सकता है. हालांकि, READ_CALL_LOG की अनुमति के बिना, PHONE_STATE_CHANGED ब्रॉडकास्ट और PhoneStateListener के ज़रिए दिया गया फ़ोन नंबर फ़ील्ड खाली रहता है.

फ़ोन की स्थिति से फ़ोन नंबर पढ़ने के लिए, अपने ऐप्लिकेशन को अपडेट करें, ताकि आप अपने इस्तेमाल के उदाहरण के आधार पर ज़रूरी अनुमतियों का अनुरोध कर सकें:

• PHONE_STATE इंटेंट ऐक्शन से संख्याएं पढ़ने के लिए, आपके पास READ_CALL_LOG और READ_PHONE_STATE, दोनों अनुमतियां होनी चाहिए.
• onCallStateChanged() से नंबर पढ़ने के लिए, आपको सिर्फ़ READ_CALL_LOG की अनुमति चाहिए. इसके लिए, आपके पास READ_PHONE_STATE की अनुमति होनी ज़रूरी नहीं है.

वाई-फ़ाई की जगह और कनेक्शन की जानकारी के ऐक्सेस पर पाबंदी लगी है

Android 9 में, किसी ऐप्लिकेशन को वाई-फ़ाई स्कैन करने के लिए, अनुमति की ज़रूरी शर्तें पिछले वर्शन के मुकाबले ज़्यादा सख्त हैं. ज़्यादा जानकारी के लिए, वाई-फ़ाई स्कैनिंग से जुड़ी पाबंदियां देखें.

ये पाबंदियां, getConnectionInfo() के लिए भी लागू होती हैं. यह तरीका, मौजूदा वाई-फ़ाई कनेक्शन की जानकारी देने वाला WifiInfo ऑब्जेक्ट दिखाता है. SSID और BSSID वैल्यू पाने के लिए, इस ऑब्जेक्ट के तरीकों का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब कॉल करने वाले ऐप्लिकेशन के पास ये अनुमतियां हों:

• ACCESS_FINE_LOCATION या ACCESS_COARSE_LOCATION
• ACCESS_WIFI_STATE

एसएसआईडी या बीएसएसआईडी पाने के लिए, यह ज़रूरी है कि डिवाइस पर जगह की जानकारी की सेवाएं चालू हों. इसके लिए, सेटिंग > जगह की जानकारी पर जाएं.

वाई-फ़ाई सेवा के तरीकों से हटाई गई जानकारी

Android 9 में, यहां दिए गए इवेंट और ब्रॉडकास्ट को उपयोगकर्ता की जगह या निजी पहचान से जुड़े डेटा की जानकारी नहीं मिलती:

• WifiManager से मिले getScanResults() और getConnectionInfo() तरीके.
• WifiP2pManager से discoverServices() और addServiceRequest() के तरीके.
• NETWORK_STATE_CHANGED_ACTION ब्रॉडकास्ट.

NETWORK_STATE_CHANGED_ACTION वाई-फ़ाई से किए जाने वाले सिस्टम ब्रॉडकास्ट में अब SSID (पहले EXTRA_SSID), BSSID (पहले EXTRA_BSSID) या कनेक्शन की जानकारी (पहले EXTRA_NETWORK_INFO) शामिल नहीं होती. अगर आपके ऐप्लिकेशन को यह जानकारी चाहिए, तो इसके बजाय getConnectionInfo() को कॉल करें.

टेलीफ़ोन की जानकारी अब डिवाइस की जगह की जानकारी की सेटिंग पर निर्भर करती है

अगर उपयोगकर्ता ने Android 9 वाले डिवाइस पर डिवाइस की जगह की जानकारी की सुविधा बंद की है, तो नीचे दिए गए तरीके काम नहीं करेंगे:

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

ऐसे इंटरफ़ेस के इस्तेमाल पर पाबंदियां जो SDK टूल में उपलब्ध नहीं हैं

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

SDK टूल के अलावा अन्य इंटरफ़ेस पर पाबंदियां में ज़्यादा अहम जानकारी दी गई है. आपको इसकी समीक्षा करनी चाहिए, ताकि यह पक्का किया जा सके कि आपका ऐप्लिकेशन ठीक से काम करता रहे.

सुरक्षा से जुड़े व्यवहार में बदलाव

डिवाइस की सुरक्षा से जुड़े बदलाव

Android 9 में कई सुविधाएं जोड़ी गई हैं, जिनसे आपके ऐप्लिकेशन की सुरक्षा बेहतर होती है. भले ही, आपका ऐप्लिकेशन किसी भी वर्शन को टारगेट करता हो.

टीएलएस लागू करने से जुड़े बदलाव

Android 9 में, सिस्टम के TLS लागू करने के तरीके में कई बदलाव किए गए हैं:

• अगर SSLSocket का कोई इंस्टेंस बनाने के दौरान कनेक्ट नहीं हो पाता है, तो सिस्टम NullPointerException के बजाय IOException दिखाता है.
• SSLEngine क्लास, close_notify से जुड़ी सभी सूचनाओं को आसानी से मैनेज करती है.

Android ऐप्लिकेशन में सुरक्षित वेब अनुरोध करने के बारे में ज़्यादा जानने के लिए, एचटीटीपीएस का एक उदाहरण देखें.

सख्त SECCOMP फ़िल्टर

Android 9, ऐप्लिकेशन के लिए उपलब्ध सिस्टम कॉल पर और भी पाबंदियां लगाता है. यह व्यवहार, SECCOMP फ़िल्टर का एक एक्सटेंशन है, जो Android 8.0 (एपीआई लेवल 26) में शामिल है.

क्रिप्टोग्राफ़ी से जुड़े बदलाव

Android 9 में, क्रिप्टोग्राफ़िक एल्गोरिदम को लागू करने और मैनेज करने के तरीके में कई बदलाव किए गए हैं.

पैरामीटर और एल्गोरिदम के लिए Conscrypt का इस्तेमाल

Android 9 में, Conscrypt में एल्गोरिदम पैरामीटर के अतिरिक्त लागू किए गए हैं. इन पैरामीटर में ये शामिल हैं: AES, DESEDE, OAEP, और EC. Android 9 के बाद, इन पैरामीटर और कई एल्गोरिदम के Bouncy Castle वर्शन का इस्तेमाल नहीं किया जा सकता.

अगर आपका ऐप्लिकेशन Android 8.1 (एपीआई लेवल 27) या उससे पहले के वर्शन को टारगेट करता है, तो इनमें से किसी एक अल्गोरिदम को Bouncy Castle के ज़रिए लागू करने का अनुरोध करने पर, आपको चेतावनी मिलेगी. हालांकि, Android 9 को टारगेट करने पर, इनमें से हर अनुरोध के लिए NoSuchAlgorithmException दिखता है.

अन्य बदलाव

Android 9 में क्रिप्टोग्राफ़ी से जुड़े कई अन्य बदलाव किए गए हैं:

• PBE पासकोड का इस्तेमाल करते समय, अगर Bouncy Castle को कोई शुरू करने वाला वेक्टर (IV) चाहिए और आपका ऐप्लिकेशन कोई वेक्टर नहीं देता है, तो आपको चेतावनी मिलती है.
• ARC4 सिफर के Conscrypt लागू करने की सुविधा से, ARC4/ECB/NoPadding या ARC4/NONE/NoPadding में से किसी एक को चुना जा सकता है.
• Crypto Java Cryptography Architecture (JCA) प्रोवाइडर को हटा दिया गया है. इस वजह से, अगर आपका ऐप्लिकेशन SecureRandom.getInstance("SHA1PRNG", "Crypto") को कॉल करता है, तो NoSuchProviderException दिखता है.
• अगर आपका ऐप्लिकेशन, बफ़र से आरएसए कुंजियों को पार्स करता है, जो कुंजी के स्ट्रक्चर से बड़ी हैं, तो अपवाद नहीं दिखता.

Android की क्रिप्टोग्राफ़ी की सुविधाओं को इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, क्रिप्टोग्राफ़ी लेख पढ़ें.

Android पर, एन्क्रिप्ट (सुरक्षित) की गई फ़ाइलों को अब ऐक्सेस नहीं किया जा सकता

Android 9 में, Android की सुरक्षित एन्क्रिप्ट की गई फ़ाइलों (ASECs) के लिए पूरी तरह से सहायता हटा दी गई है.

Android 2.2 (एपीआई लेवल 8) में, Android ने एसडी कार्ड पर ऐप्लिकेशन सेव करने की सुविधा के साथ काम करने के लिए, एएसईसी को पेश किया था. Android 6.0 (एपीआई लेवल 23) पर, प्लैटफ़ॉर्म ने डिवाइस में स्टोरेज के लिए इस्तेमाल किए जा सकने वाले डिवाइस की टेक्नोलॉजी को लॉन्च किया था. डेवलपर इसका इस्तेमाल, ASECs के बजाय कर सकते हैं.

ICU लाइब्रेरी से जुड़े अपडेट

Android 9, ICU लाइब्रेरी के 60 वर्शन का इस्तेमाल करता है. Android 8.0 (एपीआई लेवल 26) और Android 8.1 (एपीआई लेवल 27) में ICU 58 का इस्तेमाल किया जाता है.

ICU का इस्तेमाल, android.icu package के नीचे सार्वजनिक एपीआई उपलब्ध कराने के लिए किया जाता है. साथ ही, इसे Android प्लैटफ़ॉर्म में अंतरराष्ट्रीय स्तर पर उपलब्ध कराने के लिए, अंदरूनी तौर पर इस्तेमाल किया जाता है. उदाहरण के लिए, इसका इस्तेमाल java.util, java.text, और android.text.format में Android क्लास लागू करने के लिए किया जाता है.

ICU 60 के अपडेट में कई छोटे, लेकिन काम के बदलाव किए गए हैं. इनमें इमोजी 5.0 के डेटा के साथ काम करने की सुविधा और तारीख/समय के बेहतर फ़ॉर्मैट शामिल हैं. इन बदलावों के बारे में ICU 59 और ICU 60 के रिलीज़ नोट में बताया गया है.

इस अपडेट में किए गए अहम बदलाव:

• प्लैटफ़ॉर्म पर टाइम ज़ोन मैनेज करने का तरीका बदल गया है.
  • प्लैटफ़ॉर्म, GMT और यूटीसी को बेहतर तरीके से मैनेज करता है. अब यूटीसी, जीएमटी का समानार्थी नहीं है.

    ICU अब जीएमटी और यूटीसी के लिए, ज़ोन के अनुवाद किए गए नाम उपलब्ध कराता है. इस बदलाव का असर, "GMT", "Etc/GMT", "UTC", "Etc/UTC", और "Zulu" जैसे ज़ोन के लिए, android.icu के फ़ॉर्मैट और पार्स करने के तरीके पर पड़ेगा.

  • java.text.SimpleDateFormat अब यूटीसी /जीएमटी के लिए डिसप्ले नेम देने के लिए, आईसीयू का इस्तेमाल करता है. इसका मतलब है कि:
    • zzzz को फ़ॉर्मैट करने पर, कई भाषाओं के लिए, स्थानीय भाषा में लिखी गई लंबी स्ट्रिंग जनरेट होती है. पहले, यह यूटीसी के लिए "यूटीसी" और जीएमटी के लिए "जीएमटी+00:00" जैसी स्ट्रिंग दिखाता था.
    • zzzz को पार्स करने पर, "यूनिवर्सल कोऑर्डिनेटेड टाइम" और "ग्रीनविच मीन टाइम" जैसी स्ट्रिंग की पहचान की जाती है.
    • अगर ऐप्लिकेशन यह मानते हैं कि "यूटीसी" या "GMT+00:00", सभी भाषाओं में zzzz के लिए आउटपुट है, तो उन्हें काम करने में समस्याएं आ सकती हैं.
  • java.text.DateFormatSymbols.getZoneStrings() के काम करने का तरीका बदल गया है:
    • SimpleDateFormat की तरह ही, यूटीसी और जीएमटी के लिए अब लंबे नाम इस्तेमाल किए जाते हैं. यूटीसी ज़ोन के लिए, टाइम ज़ोन के नामों के डीएसटी वैरिएंट, जैसे कि "यूटीसी", "Etc/यूटीसी", और "ज़ुलु", GMT+00:00 हो जाते हैं. यह स्टैंडर्ड फ़ॉलबैक होता है, जो नाम उपलब्ध न होने पर, हार्ड कोड की गई स्ट्रिंग UTC के बजाय इस्तेमाल किया जाता है.
    • कुछ ज़ोन आईडी को, दूसरे ज़ोन के लिए सही वैकल्पिक शब्दों के तौर पर पहचाना जाता है. इससे Android को Eire जैसे पुराने ज़ोन आईडी के लिए स्ट्रिंग मिलती हैं, जिन्हें पहले हल नहीं किया जा सकता था.
  • Asia/Hanoi अब मान्य ज़ोन नहीं है. इस वजह से, java.util.TimeZones.getAvailableIds() यह वैल्यू नहीं दिखाता और java.util.TimeZone.getTimeZone() इसे पहचान नहीं पाता. यह व्यवहार, android.icu के मौजूदा व्यवहार के मुताबिक है.
• android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) तरीके से, मुद्रा के मान्य टेक्स्ट को पार्स करते समय भी ParseException दिख सकता है. PLURALCURRENCYSTYLE स्टाइल में मुद्रा के टेक्स्ट के लिए, NumberFormat.parseCurrency का इस्तेमाल करके इस समस्या से बचें. यह सुविधा, Android 7.0 (एपीआई लेवल 24) से उपलब्ध है.

Android टेस्ट में हुए बदलाव

Android 9 में, Android टेस्ट फ़्रेमवर्क की लाइब्रेरी और क्लास स्ट्रक्चर में कई बदलाव किए गए हैं. इन बदलावों से डेवलपर को फ़्रेमवर्क के साथ काम करने वाले, सार्वजनिक एपीआई का इस्तेमाल करने में मदद मिलती है. साथ ही, इन बदलावों से तीसरे पक्ष की लाइब्रेरी या कस्टम लॉजिक का इस्तेमाल करके, टेस्ट बनाने और चलाने में ज़्यादा आसानी होती है.

फ़्रेमवर्क से हटाई गई लाइब्रेरी

Android 9, JUnit पर आधारित क्लास को तीन लाइब्रेरी में फिर से व्यवस्थित करता है: android.test.base, android.test.runner, और android.test.mock. इस बदलाव की मदद से, JUnit के उस वर्शन के लिए टेस्ट चलाए जा सकते हैं जो आपके प्रोजेक्ट की डिपेंडेंसी के साथ सबसे बेहतर तरीके से काम करता है. JUnit का यह वर्शन, android.jar के दिए गए वर्शन से अलग हो सकता है.

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

टेस्ट सुइट के बिल्ड में हुए बदलावों की जांच करना

TestSuiteBuilder क्लास में addRequirements() तरीका हटा दिया गया है. साथ ही, TestSuiteBuilder क्लास को भी बंद कर दिया गया है. addRequirements() तरीके में, डेवलपर को ऐसे आर्ग्युमेंट देने होते थे जिनके टाइप, छिपे हुए एपीआई होते हैं. इससे एपीआई अमान्य हो जाता है.

Java UTF डीकोडर

Android में UTF-8 डिफ़ॉल्ट चरित्र सेट है. UTF-8 बाइट सीक्वेंस को String कन्स्ट्रक्टर, जैसे कि String(byte[] bytes) से डिकोड किया जा सकता है.

Android 9 में मौजूद UTF-8 डिकोडर, यूनिकोड स्टैंडर्ड का पालन, पिछले वर्शन की तुलना में ज़्यादा सख्ती से करता है. इन बदलावों में ये शामिल हैं:

• UTF-8 के सबसे छोटे फ़ॉर्म के अलावा, किसी दूसरे फ़ॉर्म को गलत माना जाता है. जैसे, <C0, AF>.
• UTF-8 के सरोगेट फ़ॉर्म, जैसे कि U+D800..U+DFFF को गलत फ़ॉर्मैट माना जाता है.
• ज़्यादा से ज़्यादा सब-पार्ट को एक U+FFFD से बदल दिया जाता है. उदाहरण के लिए, बाइट क्रम "41 C0 AF 41 F4 80 80 41" में, सबसे ज़्यादा सब-पार्ट "C0," "AF," और "F4 80 80" हैं."F4 80 80", "F4 80 80 80" का शुरुआती सब-सीक्वेंस हो सकता है, लेकिन "C0", किसी भी सही कोड यूनिट सीक्वेंस का शुरुआती सब-सीक्वेंस नहीं हो सकता. इसलिए, आउटपुट "A\ufffd\ufffdA\ufffdA" होना चाहिए.
• Android 9 या उसके बाद के वर्शन में, बदले गए UTF-8 / CESU-8 क्रम को डिकोड करने के लिए, DataInputStream.readUTF() या NewStringUTF() JNI तरीके का इस्तेमाल करें.

सर्टिफ़िकेट का इस्तेमाल करके होस्टनेम की पुष्टि करना

आरएफ़सी 2818 में, डोमेन नेम को सर्टिफ़िकेट से मैच करने के दो तरीके बताए गए हैं. पहला, subjectAltName (SAN) एक्सटेंशन में मौजूद नामों का इस्तेमाल करके और दूसरा, SAN एक्सटेंशन न होने पर, commonName (CN) का इस्तेमाल करके.

हालांकि, आरएफ़सी 2818 में CN पर फ़ॉलबैक करने की सुविधा को बंद कर दिया गया था. इस वजह से, Android अब CN का इस्तेमाल नहीं करता. किसी होस्टनेम की पुष्टि करने के लिए, सर्वर को SAN से मैच करने वाला सर्टिफ़िकेट दिखाना होगा. जिन सर्टिफ़िकेट में होस्टनेम से मैच करने वाला SAN नहीं होता उन पर अब भरोसा नहीं किया जाता.

नेटवर्क पते के लुकअप की वजह से, नेटवर्क से जुड़े उल्लंघन हो सकते हैं

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

StrictMode क्लास, डेवलपमेंट टूल है. इससे डेवलपर को अपने कोड में समस्याओं का पता लगाने में मदद मिलती है.

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

आपको अपने ऐप्लिकेशन को StrictMode चालू करके शिप नहीं करना चाहिए. ऐसा करने पर, आपके ऐप्लिकेशन में अपवाद दिख सकते हैं. जैसे, नेटवर्क के उल्लंघनों का पता लगाने वाली नीति पाने के लिए, NetworkOnMainThreadException या detectAll() तरीकों का इस्तेमाल करने पर.detectNetwork()

अंकों वाले आईपी पते को हल करने को ब्लॉक करने की कार्रवाई नहीं माना जाता. अंकों वाले आईपी पते का रिज़ॉल्यूशन, Android 9 से पहले के वर्शन की तरह ही काम करता है.

सॉकेट टैगिंग

Android 9 से पहले के प्लैटफ़ॉर्म वर्शन में, अगर किसी सोकेट को setThreadStatsTag() तरीके का इस्तेमाल करके टैग किया जाता है, तो ParcelFileDescriptor कंटेनर के साथ बाइंडर आईपीसी का इस्तेमाल करके, उसे किसी दूसरी प्रोसेस पर भेजने पर, सोकेट को अनटैग कर दिया जाता है.

Android 9 और उसके बाद के वर्शन में, जब किसी प्रोसेस को बाइंडर आईपीसी का इस्तेमाल करके किसी दूसरी प्रोसेस को भेजा जाता है, तो सॉकेट टैग को सेव रखा जाता है. इस बदलाव से, नेटवर्क ट्रैफ़िक के आंकड़ों पर असर पड़ सकता है. उदाहरण के लिए, queryDetailsForUidTag() तरीके का इस्तेमाल करते समय.

अगर आपको पिछले वर्शन का व्यवहार बनाए रखना है, जो किसी दूसरी प्रोसेस में भेजे गए सोकेट को अनटैग करता है, तो सोकेट भेजने से पहले untagSocket() को कॉल किया जा सकता है.

सॉकेट में उपलब्ध बाइट की संख्या

shutdownInput() तरीके को शुरू करने के बाद, available() तरीके को शुरू करने पर, यह 0 दिखाता है.

वीपीएन के लिए, नेटवर्क की क्षमताओं की ज़्यादा जानकारी वाली रिपोर्ट

Android 8.1 (एपीआई लेवल 27) और इससे पहले के वर्शन में, NetworkCapabilities क्लास सिर्फ़ वीपीएन के लिए जानकारी के सीमित सेट की जानकारी देता था. जैसे, TRANSPORT_VPN, लेकिन NET_CAPABILITY_NOT_VPN को शामिल नहीं करता था. सीमित जानकारी की वजह से, यह तय करना मुश्किल था कि वीपीएन का इस्तेमाल करने पर, ऐप्लिकेशन के उपयोगकर्ता से शुल्क लिया जाएगा या नहीं. उदाहरण के लिए, NET_CAPABILITY_NOT_METERED की जांच करने से यह पता नहीं चलेगा कि नेटवर्क को मेज़र किया गया था या नहीं.

Android 9 और इसके बाद के वर्शन में, जब कोई वीपीएन setUnderlyingNetworks() विधि को कॉल करता है, तो Android सिस्टम, किसी भी नेटवर्क के ट्रांसपोर्ट और सुविधाओं को मर्ज कर देता है. साथ ही, वीपीएन नेटवर्क की असरदार नेटवर्क सुविधाओं के तौर पर नतीजा दिखाता है.

Android 9 और उसके बाद के वर्शन में, ऐसे ऐप्लिकेशन जिन्होंने पहले से ही NET_CAPABILITY_NOT_METERED की जांच की है उन्हें वीपीएन और उसके पीछे काम करने वाले नेटवर्क की सुविधाएं मिलती हैं.

xt_qtaguid फ़ोल्डर में मौजूद फ़ाइलें, अब ऐप्लिकेशन के लिए उपलब्ध नहीं हैं

Android 9 से, ऐप्लिकेशन के पास /proc/net/xt_qtaguid फ़ोल्डर में मौजूद फ़ाइलों को सीधे पढ़ने का ऐक्सेस नहीं होगा. ऐसा इसलिए किया जाता है, ताकि उन डिवाइसों पर भी एक जैसा अनुभव मिल सके जिनमें ये फ़ाइलें मौजूद नहीं हैं.

TrafficStats और NetworkStatsManager फ़ाइलों पर निर्भर सार्वजनिक एपीआई, पहले की तरह काम करते रहेंगे. हालांकि, qtaguid_tagSocket() जैसे cutils के काम न करने वाले फ़ंक्शन, अलग-अलग डिवाइसों पर उम्मीद के मुताबिक या शायद बिलकुल भी काम न करें.

FLAG_ACTIVITY_NEW_TASK की ज़रूरी शर्त अब लागू की गई है

Android 9 में, किसी गतिविधि के अलावा किसी अन्य कॉन्टेक्स्ट से गतिविधि तब तक शुरू नहीं की जा सकती, जब तक इंटेंट फ़्लैग FLAG_ACTIVITY_NEW_TASK पास नहीं किया जाता. अगर इस फ़्लैग को पास किए बिना कोई गतिविधि शुरू की जाती है, तो गतिविधि शुरू नहीं होती और सिस्टम लॉग में एक मैसेज प्रिंट करता है.

स्क्रीन घुमाने की सुविधा में बदलाव

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

जब डिवाइस रोटेशन लॉक मोड में होता है, तो उपयोगकर्ता अपनी स्क्रीन को सबसे ऊपर दिखने वाली ऐक्टिविटी के हिसाब से, किसी भी रोटेशन में लॉक कर सकते हैं. किसी गतिविधि को यह नहीं मानना चाहिए कि उसे हमेशा पोर्ट्रेट मोड में रेंडर किया जाएगा. अगर टॉप ऐक्टिविटी को ऑटो-रोटेट मोड में कई रोटेशन में रेंडर किया जा सकता है, तो रोटेशन लॉक मोड में भी वही विकल्प उपलब्ध होने चाहिए. हालांकि, ऐक्टिविटी की screenOrientation सेटिंग के आधार पर कुछ अपवाद हो सकते हैं. इनके बारे में जानने के लिए, नीचे दी गई टेबल देखें.

किसी खास ओरिएंटेशन (उदाहरण के लिए, screenOrientation=landscape) का अनुरोध करने वाली गतिविधियां, उपयोगकर्ता के लॉक की प्राथमिकता को अनदेखा करती हैं और Android 8.0 की तरह ही काम करती हैं.

स्क्रीन ओरिएंटेशन की प्राथमिकता, Android मेनिफ़ेस्ट में गतिविधि के लेवल पर सेट की जा सकती है. इसके अलावा, setRequestedOrientation() की मदद से प्रोग्राम के हिसाब से भी इसे सेट किया जा सकता है.

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

• जब कोई उपयोगकर्ता रोटेशन का सुझाव स्वीकार करता है, तो रोटेशन की सेटिंग उस सुझाव में बदल जाती है.
• जब उपयोगकर्ता, लॉक स्क्रीन या लॉन्चर जैसे ऐसे ऐप्लिकेशन पर स्विच करता है जिनमें डिवाइस के रोटेट होने की सुविधा नहीं होती, तो रोटेशन की प्राथमिकता पोर्ट्रेट मोड में बदल जाती है.

नीचे दी गई टेबल में, स्क्रीन के आम ओरिएंटेशन के लिए, रोटेशन के व्यवहार की खास जानकारी दी गई है:

स्क्रीन अभिविन्यास	व्यवहार
अन्य, उपयोगकर्ता	अपने-आप घूमने और रोटेशन लॉक की सुविधा में, ऐक्टिविटी को पोर्ट्रेट या लैंडस्केप मोड में रेंडर किया जा सकता है. पोर्ट्रेट और लैंडस्केप, दोनों लेआउट के साथ काम करता है.
userLandscape	अपने-आप घूमने और घुमाव को लॉक करने की सुविधा में, गतिविधि को लैंडस्केप या रिवर्स लैंडस्केप में रेंडर किया जा सकता है. सिर्फ़ लैंडस्केप लेआउट के साथ काम करेगा.
userPortrait	अपने-आप घूमने और रोटेशन लॉक की सुविधा में, ऐक्टिविटी को पोर्ट्रेट या रिवर्स पोर्ट्रेट में रेंडर किया जा सकता है. सिर्फ़ पोर्ट्रेट लेआउट के साथ काम करेगा.
fullUser	अपने-आप घूमने और रोटेशन लॉक की सुविधा में, ऐक्टिविटी को पोर्ट्रेट या लैंडस्केप मोड में रेंडर किया जा सकता है. यह सुविधा, पोर्ट्रेट और लैंडस्केप, दोनों लेआउट के साथ काम करेगी. रोटेशन लॉक का इस्तेमाल करने वाले लोगों को, रिवर्स पोर्ट्रेट में लॉक करने का विकल्प मिलेगा. आम तौर पर, यह विकल्प 180º पर लॉक होता है.
sensor, fullSensor, sensorPortrait, sensorLandscape	रोटेशन लॉक मोड की सेटिंग को अनदेखा कर दिया जाता है और इसे इस तरह से माना जाता है जैसे कि ऑटो-रोटेट की सुविधा चालू हो. इसका इस्तेमाल सिर्फ़ असाधारण मामलों में करें. साथ ही, यूज़र एक्सपीरियंस को ध्यान में रखें.

Apache HTTP क्लाइंट के बंद होने का असर, ऐसे ऐप्लिकेशन पर पड़ता है जिनमें स्टैंडर्ड क्लासलोडर का इस्तेमाल नहीं किया गया है

Android 6.0 के साथ, हमने Apache HTTP क्लाइंट के लिए सहायता हटा दी है. इस बदलाव का उन ज़्यादातर ऐप्लिकेशन पर कोई असर नहीं पड़ेगा जो Android 9 या उसके बाद के वर्शन को टारगेट नहीं करते. हालांकि, इस बदलाव का असर उन कुछ ऐप्लिकेशन पर पड़ सकता है जो स्टैंडर्ड ClassLoader स्ट्रक्चर का इस्तेमाल नहीं करते. भले ही, वे ऐप्लिकेशन Android 9 या उसके बाद के वर्शन को टारगेट न करते हों.

अगर कोई ऐप्लिकेशन ऐसे ClassLoader का इस्तेमाल करता है जो साफ़ तौर पर सिस्टम ClassLoader को काम सौंपता है, तो उस पर असर पड़ सकता है. org.apache.http.* में क्लास खोजते समय, इन ऐप्लिकेशन को ऐप्लिकेशन ClassLoader को अनुमति देनी होगी. अगर वे सिस्टम ClassLoader को काम सौंपते हैं, तो ऐप्लिकेशन Android 9 या इसके बाद के वर्शन पर NoClassDefFoundError के साथ काम नहीं करेंगे, क्योंकि सिस्टम ClassLoader को अब उन क्लास के बारे में नहीं पता है. आने वाले समय में ऐसी समस्याओं से बचने के लिए, ऐप्लिकेशन को सीधे सिस्टम ClassLoader को ऐक्सेस करने के बजाय, ऐप्लिकेशन ClassLoader के ज़रिए क्लास लोड करनी चाहिए.

कैमरों की संख्या तय करना

Android 9 डिवाइसों पर काम करने वाले ऐप्लिकेशन, getCameraIdList() को कॉल करके, डिवाइस में मौजूद हर कैमरे का पता लगा सकते हैं. कोई ऐप्लिकेशन यह नहीं मान सकता कि डिवाइस में सिर्फ़ एक पीछे वाला कैमरा या सिर्फ़ एक सामने वाला कैमरा है.

उदाहरण के लिए, अगर आपके ऐप्लिकेशन में सामने और पीछे के कैमरे के बीच स्विच करने के लिए बटन है, तो हो सकता है कि आपके पास एक से ज़्यादा सामने या पीछे के कैमरे में से चुनने का विकल्प हो. आपको कैमरे की सूची देखनी चाहिए, हर कैमरे की विशेषताओं की जांच करनी चाहिए, और यह तय करना चाहिए कि उपयोगकर्ता को कौनसे कैमरे दिखाने हैं.