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

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

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

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

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

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

बिना SDK टूल वाले इंटरफ़ेस से जुड़ी पाबंदियां

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

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

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

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

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

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 और उसके बाद वाले वर्शन में, TLS 1.3 डिफ़ॉल्ट रूप से सभी के लिए चालू होता है TLS कनेक्शन. यहां हमारे TLS 1.3 के बारे में कुछ अहम जानकारी दी गई है लागू करना:

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

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

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

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

कनेक्ट करने की कोई भी कोशिश तब विफल होती है, जब कनेक्शन किसी ऐसी साइट से होता है जो SHA-1 का उपयोग करके बनाया गया प्रमाणपत्र.

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

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

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

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

TLS और क्रिप्टोग्राफ़ी में किए गए अन्य बदलाव

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

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

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

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

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

वाई-फ़ाई अवेयर सुविधाएं

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

इसके बाद क्लाइंट, आईपीवी6 पाने के लिए वाई-फ़ाई अवेयर नेटवर्क का अनुरोध करता है और सर्वर से मिला पोर्ट:

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 के target API की वजह से ज़रूरी शर्तें, जब किसी उपयोगकर्ता को ये चेतावनियां सिर्फ़ तब दिखती हैं, जब वह किसी ऐसे ऐप्लिकेशन को चलाता है जिसे अपडेट नहीं किया गया है हाल ही में. अन्य स्टोर से डिस्ट्रिब्यूट किए जाने वाले ऐप्लिकेशन के लिए, टारगेट एपीआई के लिए तय की गई मिलती-जुलती ज़रूरी शर्तें 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 में ऐप्लिकेशन के इस्तेमाल से जुड़े ये बदलाव किए गए हैं:

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

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

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

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

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

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

android.preference लाइब्रेरी का इस्तेमाल बंद कर दिया गया है

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

ZIP फ़ाइल की सुविधा लाइब्रेरी में बदलाव

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

इनफ़्लेटर

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

ज़िपफ़ाइल

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

ज़िपआउटपुटस्ट्रीम

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

कैमरे में हुए बदलाव

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

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

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

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

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

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

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

java.math.BigDecimal.stripTraLINGzeros() के व्यवहार में बदलाव

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

java.util.regex.Matcher और पैटर्न के व्यवहार में बदलाव

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

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

  • appendReplacement(StringBuffer, String) ने अब एक IndexOutOfBoundsException के बजाय IllegalArgumentException अगर String की जगह सिर्फ़ बैकस्लैश लिखा है, जो गैर-कानूनी है. कॉन्टेंट बनाने अगर दूसरा विकल्प 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 पर सेट कर देता है.

डिफ़ॉल्ट SUID का इस्तेमाल करके, क्रम से लगाए गए ऑब्जेक्ट के लिए लॉग इन करना

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(), लेकिन Android 10 में IO अपवाद दिखता है. अगर आपको पुराने तरीके की ज़रूरत है, तो तो आपको नेटिव कोड का इस्तेमाल करना होगा.