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

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

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

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

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

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

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

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

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

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

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

NDK

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.

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

सुरक्षा

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

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

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

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

अगर आपको ऐसा 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 से जुड़ी ये ब्रॉडकास्ट सूचनाएं नहीं दिखती हैं:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

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

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

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

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

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

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

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

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 और पोर्ट की जानकारी मिल सके:

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)

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 सीबीसी सिफ़र सुइट को प्लैटफ़ॉर्म से हटा दिया गया है:

• 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 में, ऐप्लिकेशन के इस्तेमाल से जुड़े ये बदलाव किए गए हैं:

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

• हर ऐप्लिकेशन के लिए ग्रेस्केल मोड - <0x

• हर ऐप्लिकेशन के लिए, ड्राइविंग मोड की स्थिति - <

• निलंबन और चलाने की सुविधा - <0x0

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

अगर 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 क्लास के कुछ तरीके, 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 दिखता है. अगर आपको पुरानी सुविधा का इस्तेमाल करना है, तो आपको नेटिव कोड का इस्तेमाल करना होगा.