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

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

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

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

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

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

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

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

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

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

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

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

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

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

एनडीके

Android 10 में, NDK में ये बदलाव किए गए हैं.

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

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/… पाथ को Bionic फ़ाइलों के लिए मान्य पाथ के तौर पर जोड़ा जाना चाहिए.

सिस्टम बाइनरी/लाइब्रेरी, सिर्फ़ एक्ज़ीक्यूट करने की अनुमति वाली मेमोरी पर मैप की गई हैं

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

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

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

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

सुरक्षा

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

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

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

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

TLS में, SHA-1 से हस्ताक्षर किए गए सर्टिफ़िकेट पर भरोसा नहीं किया जाता

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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();

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

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 CBC साइफ़र सुइट हटा दिए गए हैं

इन SHA-2 सीबीसी सिफ़र सुइट को प्लैटफ़ॉर्म से हटा दिया गया है:

  • 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 और CBC, दोनों वैरिएंट के साथ काम करते हैं या किसी के साथ भी काम नहीं करते.

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

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 का इस्तेमाल करने वाले अन्य प्लैटफ़ॉर्म के बीच, लाइब्रेरी के व्यवहार में ज़्यादा एकरूपता आती है.

Inflator

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

ZipFile

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

ZipOutputStream

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

कैमरे में बदलाव

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

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

बैटरी के इस्तेमाल को ट्रैक करना

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

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

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

Android 10 में, हम Android Beam को आधिकारिक तौर पर बंद कर रहे हैं. यह नियर फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के ज़रिए, डिवाइसों के बीच डेटा शेयर करने की पुरानी सुविधा है. हम NFC से जुड़े कई एपीआई भी बंद कर रहे हैं. Android बीम, डिवाइस बनाने वाली कंपनियों के लिए अब भी उपलब्ध है. हालांकि, अब इस पर काम नहीं किया जा रहा है. 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), NullPointerException दिखाता है, तो वह Matcher पर reset() को कॉल नहीं करेगा. अब कोई मैच न होने पर भी 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 का इस्तेमाल करती है.
  • अगर ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के लेवल को टारगेट करता है, तो डिफ़ॉल्ट serialVersionUID, serialVersionUID से अलग होगा.

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

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

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