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

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

अगर आपके ऐप्लिकेशन का targetSdkVersion 29 या इसके बाद का वर्शन है, तो आपको अन्य बदलावों के साथ भी काम करना होगा. ज़्यादा जानकारी के लिए, एपीआई लेवल 29 को टारगेट करने वाले ऐप्लिकेशन के काम करने के तरीके में हुए बदलाव ज़रूर पढ़ें.

ध्यान दें: इस पेज पर बताए गए बदलावों के अलावा, Android 10 में निजता से जुड़े कई बदलाव और पाबंदियां भी शामिल की गई हैं. इनमें ये शामिल हैं:

  • डिवाइस की जगह की जानकारी का बैकग्राउंड ऐक्सेस
  • बैकग्राउंड में गतिविधि शुरू होती है
  • संपर्कों से जुड़ी अफ़िनिटी की जानकारी
  • एमएसी पता बदलने की सुविधा
  • कैमरे का मेटाडेटा
  • अनुमतियों का मॉडल

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

गैर-एसडीके इंटरफ़ेस से जुड़ी पाबंदियां

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

अगर आपका ऐप्लिकेशन Android 10 (एपीआई लेवल 29) को टारगेट नहीं करता है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, फ़िलहाल कुछ गैर-एसडीके इंटरफ़ेस (आपके ऐप्लिकेशन के टारगेट एपीआई लेवल के हिसाब से) इस्तेमाल किए जा सकते हैं. हालांकि, किसी भी गैर-एसडीके तरीके या फ़ील्ड का इस्तेमाल करने से, आपके ऐप्लिकेशन के काम न करने का जोखिम हमेशा ज़्यादा होता है.

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

ज़्यादा जानने के लिए, Android 10 में गैर-एसडीके इंटरफ़ेस की पाबंदियों से जुड़े अपडेट और गैर-एसडीके इंटरफ़ेस पर पाबंदियां देखें.

जेस्चर वाला नेविगेशन

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

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

एनडीके (NDK)

Android 10 में, एनडीके से जुड़े ये बदलाव शामिल हैं.

शेयर किए गए ऑब्जेक्ट में, टेक्स्ट को दूसरी जगह पर नहीं ले जाया जा सकता

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

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

बायोनिक लाइब्रेरी और डाइनैमिक लिंकर पाथ में बदलाव

Android 10 से, कई पाथ सामान्य फ़ाइलों के बजाय सॉफ़्ट लिंक होते हैं. ऐसे ऐप्लिकेशन जो पाथ के सामान्य फ़ाइल होने पर निर्भर करते हैं वे काम करना बंद कर सकते हैं:

  • /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
  • /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
  • /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
  • /system/bin/linker -> /apex/com.android.runtime/bin/linker

ये बदलाव, फ़ाइल के 64-बिट वैरिएंट पर भी लागू होते हैं. इनमें lib/ को lib64/ से बदल दिया जाता है.

कंपैटिबिलिटी के लिए, सिंबॉलिक लिंक पुराने पाथ पर दिए गए हैं. उदाहरण के लिए, /system/lib/libc.so, /apex/com.android.runtime/lib/bionic/libc.so का सिमलिंक है. इसलिए, dlopen(“/system/lib/libc.so”) काम करता रहेगा. हालांकि, ऐप्लिकेशन को तब अंतर पता चलेगा, जब वे /proc/self/maps या इससे मिलती-जुलती चीज़ों को पढ़कर, लोड की गई लाइब्रेरी की जांच करने की कोशिश करेंगे. ऐसा आम तौर पर नहीं होता है, लेकिन हमें पता चला है कि कुछ ऐप्लिकेशन, हैकिंग से बचने की प्रोसेस के तहत ऐसा करते हैं. अगर ऐसा है, तो /apex/… पाथ को बायोनिक फ़ाइलों के लिए मान्य पाथ के तौर पर जोड़ा जाना चाहिए.

सिस्टम बाइनरी/लाइब्रेरी को एक्ज़ीक्यूट-ओनली मेमोरी में मैप किया गया

Android 10 से, सिस्टम बाइनरी और लाइब्रेरी के एक्ज़ीक्यूटेबल सेगमेंट को मेमोरी में सिर्फ़ एक्ज़ीक्यूट करने के लिए (रीड नहीं किया जा सकता) मैप किया जाता है. यह कोड-रीयूज़ अटैक से बचने की एक तकनीक है. अगर आपका ऐप्लिकेशन, मेमोरी के उन सेगमेंट में डेटा पढ़ने की प्रोसेस करता है जिन्हें सिर्फ़ एक्ज़ीक्यूट करने के लिए मार्क किया गया है, तो सिस्टम आपके ऐप्लिकेशन को SIGSEGV सिग्नल भेजता है. ऐसा तब होता है, जब मेमोरी की जांच जान-बूझकर की गई हो या फिर किसी गड़बड़ी या जोखिम की वजह से ऐसा हुआ हो.

/data/tombstones/ में मौजूद टूंबस्टोन फ़ाइल की जांच करके, यह पता लगाया जा सकता है कि इस व्यवहार की वजह से क्रैश हुआ है या नहीं. सिर्फ़ एक्ज़ीक्यूट किए जा सकने वाले क्रैश में, यह मैसेज शामिल होता है:

Cause: execute-only (no-read) memory access error; likely due to data in .text.

मेमोरी की जांच जैसे काम करने के लिए, इस समस्या को हल किया जा सकता है. इसके लिए, mprotect() को कॉल करके, सिर्फ़ एक्ज़ीक्यूट किए जा सकने वाले सेगमेंट को रीड+एक्ज़ीक्यूट के तौर पर मार्क किया जा सकता है. हालांकि, हमारा सुझाव है कि बाद में इसे फिर से 'सिर्फ़ एक्ज़ीक्यूट करें' पर सेट कर दें. ऐसा इसलिए, क्योंकि ऐक्सेस की अनुमति देने वाली यह सेटिंग, आपके ऐप्लिकेशन और उपयोगकर्ताओं को बेहतर सुरक्षा देती है.

सुरक्षा

Android 10 में सुरक्षा से जुड़े ये बदलाव शामिल हैं.

TLS 1.3 डिफ़ॉल्ट रूप से चालू है

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

  • TLS 1.3 साइफ़र सुइट को पसंद के मुताबिक नहीं बनाया जा सकता. TLS 1.3 के साथ काम करने वाले साइफ़र सुइट, TLS 1.3 के चालू होने पर हमेशा चालू रहते हैं. setEnabledCipherSuites() को कॉल करके, उन्हें बंद करने की किसी भी कोशिश को अनदेखा कर दिया जाता है.
  • जब टीएलएस 1.3 पर सहमति बन जाती है, तब सेशन कैश मेमोरी में सेशन जोड़े जाने से पहले, HandshakeCompletedListener ऑब्जेक्ट को कॉल किया जाता है. टीएलएस 1.2 और अन्य पुराने वर्शन में, इन ऑब्जेक्ट को सेशन कैश मेमोरी में सेशन जोड़ने के बाद कॉल किया जाता है.
  • कुछ मामलों में, जहां Android के पिछले वर्शन पर SSLEngine इंस्टेंस, SSLHandshakeException थ्रो करते हैं वहां Android 10 और इसके बाद के वर्शन पर ये इंस्टेंस, SSLProtocolException थ्रो करते हैं.
  • 0-RTT मोड काम नहीं करता.

अगर आप चाहें, तो SSLContext.getInstance("TLSv1.2") पर कॉल करके, ऐसा SSLContext पा सकते हैं जिसमें TLS 1.3 बंद हो. किसी सही ऑब्जेक्ट पर setEnabledProtocols() को कॉल करके, हर कनेक्शन के हिसाब से प्रोटोकॉल के वर्शन को चालू या बंद भी किया जा सकता है.

SHA-1 हस्ताक्षर वाले सर्टिफ़िकेट, टीएलएस में भरोसेमंद नहीं होते

Android 10 में, SHA-1 हैश एल्गोरिदम का इस्तेमाल करने वाले सर्टिफ़िकेट पर, टीएलएस कनेक्शन में भरोसा नहीं किया जाता. रूट सीए ने साल 2016 से ऐसा कोई सर्टिफ़िकेट जारी नहीं किया है. साथ ही, Chrome या अन्य मुख्य ब्राउज़र में अब इन पर भरोसा नहीं किया जाता.

अगर कनेक्शन किसी ऐसी साइट से है जो SHA-1 का इस्तेमाल करके सर्टिफ़िकेट दिखाती है, तो कनेक्ट करने की कोई भी कोशिश पूरी नहीं होगी.

KeyChain के काम करने के तरीके में बदलाव और सुधार

Google Chrome जैसे कुछ ब्राउज़र, उपयोगकर्ताओं को सर्टिफ़िकेट चुनने की अनुमति देते हैं. ऐसा तब होता है, जब टीएलएस हैंडशेक के दौरान, टीएलएस सर्वर सर्टिफ़िकेट के अनुरोध का मैसेज भेजता है. Android 10 से, KeyChain ऑब्जेक्ट, उपयोगकर्ताओं को सर्टिफ़िकेट चुनने का प्रॉम्प्ट दिखाने के लिए, KeyChain.choosePrivateKeyAlias() को कॉल करते समय, जारी करने वाले और मुख्य स्पेसिफ़िकेशन पैरामीटर का पालन करते हैं. खास तौर पर, इस प्रॉम्प्ट में ऐसे विकल्प शामिल नहीं होते जो सर्वर की खास बातों के मुताबिक नहीं होते.

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

इसके अलावा, Android 10 या इसके बाद के वर्शन पर, KeyChain ऑब्जेक्ट में कुंजियां या सीए सर्टिफ़िकेट इंपोर्ट करने के लिए, डिवाइस का स्क्रीन लॉक होना ज़रूरी नहीं है.

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

टीएलएस और क्रिप्टोग्राफ़ी लाइब्रेरी में कई छोटे बदलाव किए गए हैं. ये बदलाव Android 10 पर लागू होते हैं:

  • AES/GCM/NoPadding और ChaCha20/Poly1305/NoPadding साइफ़र, getOutputSize() से ज़्यादा सटीक बफ़र साइज़ दिखाते हैं.
  • टीएलएस 1.2 या इससे ऊपर के मैक्स प्रोटोकॉल के साथ कनेक्शन की कोशिशों से, TLS_FALLBACK_SCSV साइफ़र सुइट को हटा दिया जाता है. टीएलएस सर्वर को लागू करने के तरीके में सुधार होने की वजह से, हमारा सुझाव है कि टीएलएस-एक्सटर्नल फ़ॉलबैक का इस्तेमाल न करें. इसके बजाय, हमारा सुझाव है कि आप टीएलएस वर्शन नेगोशिएशन पर भरोसा करें.
  • ChaCha20-Poly1305, ChaCha20/Poly1305/NoPadding का दूसरा नाम है.
  • जिन होस्टनेम के आखिर में बिंदु होते हैं उन्हें मान्य एसएनआई होस्टनेम नहीं माना जाता.
  • सर्टिफ़िकेट के जवाबों के लिए साइनिंग पासकोड चुनते समय, CertificateRequest में supported_signature_algorithms एक्सटेंशन का ध्यान रखा जाता है.
  • Android कीस्टोर जैसी ओपेक साइनिंग कुंजियों का इस्तेमाल, टीएलएस में आरएसए-पीएसएस सिग्नेचर के साथ किया जा सकता है.

Wi-Fi Direct ब्रॉडकास्ट

Android 10 पर, Wi-Fi Direct से जुड़े ये ब्रॉडकास्ट स्टिकी नहीं होते:

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

Wi-Fi Aware की सुविधाएं

Android 10 में, Wi-Fi Aware डेटापाथ का इस्तेमाल करके टीसीपी/यूडीपी सॉकेट बनाने की सुविधा जोड़ी गई है. ServerSocket से कनेक्ट करने वाला टीसीपी/यूडीपी सॉकेट बनाने के लिए, क्लाइंट डिवाइस को सर्वर के IPv6 पते और पोर्ट की जानकारी होनी चाहिए. पहले, इस जानकारी को आउट-ऑफ़-बैंड कम्यूनिकेट करना पड़ता था. जैसे, ब्लूटूथ या Wi-Fi Aware लेयर 2 मैसेजिंग का इस्तेमाल करके. इसके अलावा, mDNS जैसे अन्य प्रोटोकॉल का इस्तेमाल करके, इन-बैंड में इस जानकारी का पता लगाया जाता था. Android 10 में, नेटवर्क सेटअप के दौरान यह जानकारी दी जा सकती है.

सर्वर इनमें से कोई भी काम कर सकता है:

  • ServerSocket को शुरू करें और इस्तेमाल किए जाने वाले पोर्ट को सेट करें या उसे हासिल करें.
  • Wi-Fi Aware नेटवर्क के अनुरोध के हिस्से के तौर पर, पोर्ट की जानकारी दें.

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

Kotlin

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

Java

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

इसके बाद, क्लाइंट IPv6 और सर्वर से मिले पोर्ट को पाने के लिए, Wi-Fi Aware नेटवर्क का अनुरोध करता है:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

Java

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

Go डिवाइसों पर SYSTEM_ALERT_WINDOW

Android 10 (Go वर्शन) वाले डिवाइसों पर चलने वाले ऐप्लिकेशन को SYSTEM_ALERT_WINDOW अनुमति नहीं मिल सकती. ऐसा इसलिए होता है, क्योंकि ओवरले विंडो बनाने में ज़्यादा मेमोरी का इस्तेमाल होता है. इससे कम मेमोरी वाले Android डिवाइसों की परफ़ॉर्मेंस पर असर पड़ता है.

अगर Android 9 या इससे पहले के वर्शन वाले Go वर्शन डिवाइस पर चल रहे किसी ऐप्लिकेशन को SYSTEM_ALERT_WINDOW की अनुमति मिलती है, तो डिवाइस को Android 10 पर अपग्रेड करने के बाद भी ऐप्लिकेशन के पास यह अनुमति बनी रहती है. हालांकि, जिन ऐप्लिकेशन के पास पहले से यह अनुमति नहीं है उन्हें डिवाइस अपग्रेड होने के बाद यह अनुमति नहीं दी जा सकती.

अगर Go डिवाइस पर मौजूद कोई ऐप्लिकेशन, ACTION_MANAGE_OVERLAY_PERMISSION कार्रवाई के साथ कोई इंटेंट भेजता है, तो सिस्टम अपने-आप अनुरोध को अस्वीकार कर देता है. साथ ही, उपयोगकर्ता को सेटिंग स्क्रीन पर ले जाता है. इस स्क्रीन पर बताया जाता है कि अनुमति नहीं दी गई है, क्योंकि इससे डिवाइस की परफ़ॉर्मेंस धीमी हो जाती है. अगर Go डिवाइस पर मौजूद कोई ऐप्लिकेशन Settings.canDrawOverlays() को कॉल करता है, तो यह तरीका हमेशा गलत नतीजे दिखाता है. ये पाबंदियां उन ऐप्लिकेशन पर लागू नहीं होती हैं जिन्हें डिवाइस को Android 10 पर अपग्रेड करने से पहले, SYSTEM_ALERT_WINDOW की अनुमति मिल गई थी.

Android के पुराने वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए चेतावनियां

Android 10 या इसके बाद के वर्शन वाले डिवाइसों पर, उपयोगकर्ताओं को पहली बार Android 5.1 (एपीआई लेवल 22) या इससे पहले के वर्शन को टारगेट करने वाला कोई ऐप्लिकेशन चलाने पर चेतावनी दी जाती है. अगर ऐप्लिकेशन को उपयोगकर्ता से अनुमतियां लेने की ज़रूरत होती है, तो उपयोगकर्ता को ऐप्लिकेशन की अनुमतियों में बदलाव करने का विकल्प भी दिया जाता है. ऐसा ऐप्लिकेशन को पहली बार चलाने से पहले किया जाता है.

Google Play की टारगेट एपीआई की ज़रूरी शर्तों की वजह से, उपयोगकर्ता को ये चेतावनियां सिर्फ़ तब दिखती हैं, जब वह कोई ऐसा ऐप्लिकेशन चलाता है जिसे हाल ही में अपडेट नहीं किया गया है. अन्य स्टोर से उपलब्ध कराए जाने वाले ऐप्लिकेशन के लिए, टारगेट एपीआई की मिलती-जुलती ज़रूरी शर्तें 2019 से लागू हो रही हैं. इन ज़रूरी शर्तों के बारे में ज़्यादा जानने के लिए, साल 2019 में टारगेट एपीआई लेवल की ज़रूरी शर्तों को बढ़ाना लेख पढ़ें.

SHA-2 सीबीसी साइफ़र सुइट हटाए गए

प्लैटफ़ॉर्म से ये SHA-2 CBC साइफ़र सुइट हटा दिए गए हैं:

  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

ये साइफ़र सुइट, GCM का इस्तेमाल करने वाले साइफ़र सुइट की तुलना में कम सुरक्षित होते हैं. ज़्यादातर सर्वर, इन साइफ़र सुइट के GCM और सीबीसी, दोनों वैरिएंट के साथ काम करते हैं या दोनों में से किसी के साथ काम नहीं करते.

ऐप्लिकेशन का उपयोग

Android 10 में, ऐप्लिकेशन के इस्तेमाल से जुड़े ये बदलाव किए गए हैं:

  • UsageStats ऐप्लिकेशन के इस्तेमाल से जुड़े आंकड़ों को बेहतर तरीके से ट्रैक करता है - Android 10, UsageStats की मदद से ऐप्लिकेशन के इस्तेमाल से जुड़े आंकड़ों को बेहतर तरीके से ट्रैक करता है. ऐसा तब होता है, जब ऐप्लिकेशन को स्प्लिट-स्क्रीन या पिक्चर में पिक्चर मोड में इस्तेमाल किया जाता है. इसके अलावा, Android 10, इंस्टैंट ऐप्लिकेशन के इस्तेमाल को सही तरीके से ट्रैक करता है.

  • हर ऐप्लिकेशन के लिए ग्रेस्केल - Android 10 में, हर ऐप्लिकेशन के लिए ग्रेस्केल डिसप्ले मोड सेट किया जा सकता है.

  • हर ऐप्लिकेशन के लिए, ध्यान भटकाने वाली स्थिति - Android 10, ऐप्लिकेशन को "ध्यान भटकाने वाली स्थिति" पर सेट कर सकता है. इससे, उन ऐप्लिकेशन की सूचनाएं नहीं दिखती हैं और वे सुझाए गए ऐप्लिकेशन के तौर पर नहीं दिखते.

  • निलंबन और प्लेबैक - Android 10 में, निलंबित किए गए ऐप्लिकेशन ऑडियो नहीं चला सकते.

एचटीटीपीएस कनेक्शन में हुए बदलाव

अगर Android 10 पर चलने वाला कोई ऐप्लिकेशन, null को setSSLSocketFactory() में पास करता है, तो IllegalArgumentException होता है. पिछले वर्शन में, null को setSSLSocketFactory() में पास करने पर वही असर होता था जो मौजूदा डिफ़ॉल्ट फ़ैक्ट्री में पास करने पर होता था.

android.preference लाइब्रेरी अब काम नहीं करती

android.preference लाइब्रेरी, Android 10 के बाद से काम नहीं करती. इसके बजाय, डेवलपर को AndroidX की Preference लाइब्रेरी का इस्तेमाल करना चाहिए. यह Android Jetpack का हिस्सा है. माइग्रेशन और डेवलपमेंट में मदद करने वाले अन्य संसाधनों के लिए, अपडेट की गई सेटिंग गाइड देखें. साथ ही, हमारा सार्वजनिक सैंपल ऐप्लिकेशन और रेफ़रंस दस्तावेज़ देखें.

ZIP फ़ाइल यूटिलिटी लाइब्रेरी में बदलाव

Android 10 में, java.util.zip पैकेज की क्लास में ये बदलाव किए गए हैं. यह पैकेज, ZIP फ़ाइलों को मैनेज करता है. इन बदलावों से, Android और java.util.zip का इस्तेमाल करने वाले अन्य प्लैटफ़ॉर्म पर, लाइब्रेरी का व्यवहार ज़्यादा एक जैसा हो जाता है.

Inflater

पिछले वर्शन में, Inflater क्लास के कुछ तरीके IllegalStateException दिखाते थे, अगर उन्हें end() को कॉल करने के बाद शुरू किया जाता था. Android 10 में, ये तरीके इसके बजाय NullPointerException दिखाते हैं.

ZipFile

Android 10 और इसके बाद के वर्शन में, ZipFile के लिए कंस्ट्रक्टर, File, int, और Charset टाइप के आर्ग्युमेंट लेता है. अगर दी गई ZIP फ़ाइल में कोई फ़ाइल नहीं है, तो यह ZipException को थ्रो नहीं करता है.

ZipOutputStream

Android 10 और इसके बाद के वर्शन में, ZipOutputStream में मौजूद finish() मेथड, ZipException को थ्रो नहीं करता है. ऐसा तब होता है, जब वह किसी ऐसी ZIP फ़ाइल के लिए आउटपुट स्ट्रीम लिखने की कोशिश करता है जिसमें कोई फ़ाइल मौजूद नहीं है.

कैमरे में किए गए बदलाव

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

एपीआई लेवल 24 या इसके बाद के लेवल को टारगेट करने वाले ऐप्लिकेशन को साफ़ तौर पर android:resizeableActivity सेट करना चाहिए. साथ ही, मल्टी-विंडो ऑपरेशन को मैनेज करने के लिए ज़रूरी फ़ंक्शन उपलब्ध कराना चाहिए.

बैटरी खर्च की जानकारी ट्रैक करना

Android 10 से, SystemHealthManager बैटरी के इस्तेमाल से जुड़े आंकड़ों को रीसेट कर देता है. ऐसा तब होता है, जब डिवाइस को बैटरी चार्ज होने के बाद अनप्लग किया जाता है. आम तौर पर, चार्जिंग से जुड़ा कोई बड़ा इवेंट इनमें से कोई एक होता है: डिवाइस पूरी तरह से चार्ज हो गया है या डिवाइस की बैटरी ज़्यादातर खत्म होने से लेकर ज़्यादातर चार्ज होने तक की स्थिति में पहुंच गई है.

Android 10 से पहले, बैटरी के इस्तेमाल के आंकड़े तब रीसेट हो जाते थे, जब डिवाइस को चार्जिंग से हटाया जाता था. भले ही, बैटरी लेवल में कितना भी कम बदलाव हुआ हो.

Android Beam की सुविधा बंद करना

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

java.math.BigDecimal.stripTrailingZeros() के काम करने के तरीके में बदलाव

अगर इनपुट वैल्यू शून्य है, तो BigDecimal.stripTrailingZeros() अब खास मामले के तौर पर, बाद में आने वाले शून्य को सेव नहीं रखता.

java.util.regex.Matcher और Pattern के व्यवहार में बदलाव

split() के नतीजे में बदलाव किया गया है, ताकि इनपुट की शुरुआत में शून्य-चौड़ाई वाला मैच होने पर, अब खाली String ("") से शुरुआत न हो. इससे String.split() पर भी असर पड़ता है. उदाहरण के लिए, "x".split("") से अब नतीजे के तौर पर {"x"} मिलता है. हालांकि, Android के पुराने वर्शन पर इससे {"", "x"} मिलता था. "aardvark".split("(?=a)" अब {"", "a", "ardv", "ark"} के बजाय {"a", "ardv", "ark"} दिखाता है.

अमान्य आर्ग्युमेंट के लिए, अपवाद के व्यवहार को भी बेहतर बनाया गया है:

  • अगर रिप्लेसमेंट String, बैकस्लैश के साथ खत्म होता है, तो appendReplacement(StringBuffer, String) अब IndexOutOfBoundsException के बजाय IllegalArgumentException दिखाता है. ऐसा करना गलत है. अगर रिप्लेसमेंट String, $ पर खत्म होता है, तो अब वही अपवाद दिखता है. पहले, इस स्थिति में कोई अपवाद नहीं दिखता था.
  • replaceFirst(null), Matcher पर reset() को कॉल नहीं करता, अगर वह NullPointerException दिखाता है. NullPointerException अब तब भी दिखता है, जब कोई मैच नहीं मिलता. पहले, यह गड़बड़ी सिर्फ़ तब दिखती थी, जब कोई मैच मिलता था.
  • start(int group), end(int group), और group(int group) अब ज़्यादा सामान्य IndexOutOfBoundsException थ्रो करते हैं, अगर ग्रुप इंडेक्स सीमा से बाहर है. पहले, इन तरीकों से ArrayIndexOutOfBoundsException मिलता था.

GradientDrawable के लिए डिफ़ॉल्ट ऐंगल अब TOP_BOTTOM है

Android 10 में, अगर एक्सएमएल में GradientDrawable को तय किया जाता है और ऐंगल मेज़रमेंट नहीं दिया जाता है, तो ग्रेडिएंट ओरिएंटेशन डिफ़ॉल्ट रूप से TOP_BOTTOM पर सेट हो जाता है. यह Android के पिछले वर्शन से अलग है, जहां डिफ़ॉल्ट रूप से LEFT_RIGHT था.

इसके बजाय, अगर AAPT2 के सबसे नए वर्शन पर अपडेट किया जाता है, तो टूल लेगसी ऐप्लिकेशन के लिए, ऐंगल मेज़रमेंट को 0 पर सेट कर देता है. ऐसा तब होता है, जब ऐंगल मेज़रमेंट की जानकारी न दी गई हो.

डिफ़ॉल्ट एसयूआईडी का इस्तेमाल करके, सीरियलाइज़ किए गए ऑब्जेक्ट के लिए लॉगिंग

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

Android 10 से, अगर कोई ऐप्लिकेशन एपीआई लेवल 23 या इससे पहले के लेवल को टारगेट करता है और पुराने, गलत, डिफ़ॉल्ट serialVersionUID पर निर्भर करता है, तो सिस्टम चेतावनी को लॉग करता है और कोड को ठीक करने का सुझाव देता है.

खास तौर पर, सिस्टम चेतावनी तब लॉग करता है, जब ये सभी बातें सही हों:

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

यह चेतावनी, हर उस क्लास के लिए एक बार लॉग की जाती है जिस पर असर पड़ा है. चेतावनी वाले मैसेज में, समस्या को ठीक करने का सुझाव शामिल होता है. इसमें serialVersionUID को उस डिफ़ॉल्ट वैल्यू पर सेट करने के लिए कहा जाता है जिसका हिसाब तब लगाया जाता, जब ऐप्लिकेशन एपीआई लेवल 24 या इसके बाद के लेवल को टारगेट करता. इस समस्या को ठीक करने के बाद, यह पक्का किया जा सकता है कि अगर उस क्लास के किसी ऑब्जेक्ट को टारगेट एपीआई लेवल 23 या इससे पहले के लेवल को टारगेट करने वाले ऐप्लिकेशन पर सीरियलाइज़ किया जाता है, तो उस ऑब्जेक्ट को 24 या इससे बाद के लेवल को टारगेट करने वाले ऐप्लिकेशन सही तरीके से पढ़ पाएंगे. साथ ही, इसका उल्टा भी सही होगा.

java.io.FileChannel.map() में बदलाव

Android 10 से, FileChannel.map() का इस्तेमाल /dev/zero जैसी नॉन-स्टैंडर्ड फ़ाइलों के लिए नहीं किया जा सकता. इनका साइज़, truncate() का इस्तेमाल करके नहीं बदला जा सकता. Android के पिछले वर्शन, truncate() से मिले errno को स्वीकार कर लेते थे. हालांकि, Android 10 में IOException दिखता है. अगर आपको पुरानी सुविधा का इस्तेमाल करना है, तो आपको नेटिव कोड का इस्तेमाल करना होगा.