আচরণ পরিবর্তন: সমস্ত অ্যাপ্লিকেশন

অ্যান্ড্রয়েড 10-এর মধ্যে এমন আচরণের পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি অ্যাপ্লিকেশানের targetSdkVersion নির্বিশেষে Android 10 এ চলাকালীন আপনার অ্যাপে প্রযোজ্য। এই পরিবর্তনগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনাকে আপনার অ্যাপটি পরীক্ষা করা উচিত এবং প্রয়োজন অনুসারে এটি সংশোধন করা উচিত।

আপনার অ্যাপের টার্গেটSdkVersion 29 বা তার বেশি হলে, আপনাকে অতিরিক্ত পরিবর্তন সমর্থন করতে হবে। বিশদ বিবরণের জন্য 29 টার্গেট করা অ্যাপগুলির আচরণের পরিবর্তনগুলি পড়তে ভুলবেন না।

দ্রষ্টব্য: এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি ছাড়াও, Android 10 নিম্নলিখিতগুলি সহ প্রচুর পরিমাণে গোপনীয়তা-ভিত্তিক পরিবর্তন এবং বিধিনিষেধ প্রবর্তন করে:

  • ডিভাইসের অবস্থানে ব্যাকগ্রাউন্ড অ্যাক্সেস
  • পটভূমি কার্যকলাপ শুরু হয়
  • পরিচিতি সম্বন্ধ তথ্য
  • MAC ঠিকানা র্যান্ডমাইজেশন
  • ক্যামেরা মেটাডেটা
  • অনুমতি মডেল

এই পরিবর্তনগুলি সমস্ত অ্যাপকে প্রভাবিত করে এবং ব্যবহারকারীর গোপনীয়তা বাড়ায়। এই পরিবর্তনগুলিকে কীভাবে সমর্থন করবেন সে সম্পর্কে আরও জানতে, গোপনীয়তা পরিবর্তন পৃষ্ঠাটি দেখুন।

অ-SDK ইন্টারফেস সীমাবদ্ধতা

অ্যাপের স্থিতিশীলতা এবং সামঞ্জস্যতা নিশ্চিত করতে সাহায্য করার জন্য, প্ল্যাটফর্মটি Android 9 (API স্তর 28) এ আপনার অ্যাপ ব্যবহার করতে পারে এমন নন-SDK ইন্টারফেসগুলিকে সীমাবদ্ধ করা শুরু করেছে। Android 10-এ Android বিকাশকারীদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। আমাদের লক্ষ্য হল আমরা নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে তা নিশ্চিত করা।

আপনি যদি Android 10 (API লেভেল 29) টার্গেট না করেন তবে এই পরিবর্তনগুলির মধ্যে কিছু আপনাকে অবিলম্বে প্রভাবিত করতে পারে না। যাইহোক, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে ), যেকোন নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে সবসময় আপনার অ্যাপ ভাঙার উচ্চ ঝুঁকি থাকে।

আপনি যদি নিশ্চিত না হন যে আপনার অ্যাপ নন-SDK ইন্টারফেস ব্যবহার করে, তাহলে আপনি খুঁজে বের করতে আপনার অ্যাপ পরীক্ষা করতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে স্থানান্তরের পরিকল্পনা শুরু করা উচিত। তা সত্ত্বেও, আমরা বুঝি যে কিছু অ্যাপে নন-SDK ইন্টারফেস ব্যবহার করার জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। আপনি যদি আপনার অ্যাপে একটি বৈশিষ্ট্যের জন্য একটি নন-SDK ইন্টারফেস ব্যবহার করার বিকল্প খুঁজে না পান তবে আপনাকে একটি নতুন সর্বজনীন API অনুরোধ করা উচিত।

আরও জানতে, Android 10-এ নন-SDK ইন্টারফেস বিধিনিষেধের আপডেট দেখুন এবং নন-SDK ইন্টারফেসে সীমাবদ্ধতা দেখুন।

অঙ্গভঙ্গি নেভিগেশন

Android 10 দিয়ে শুরু করে, ব্যবহারকারীরা ডিভাইস জুড়ে অঙ্গভঙ্গি নেভিগেশন সক্ষম করতে পারেন। যদি একজন ব্যবহারকারী অঙ্গভঙ্গি নেভিগেশন সক্ষম করে, তাহলে এটি ডিভাইসের সমস্ত অ্যাপকে প্রভাবিত করে, অ্যাপটি API স্তর 29 কে লক্ষ্য করে বা না করে। উদাহরণস্বরূপ, যদি ব্যবহারকারী স্ক্রিনের প্রান্ত থেকে সোয়াইপ করে, সিস্টেমটি সেই অঙ্গভঙ্গিটিকে পিছনের নেভিগেশন হিসাবে ব্যাখ্যা করে, যদি না কোনো অ্যাপ স্ক্রিনের অংশগুলির জন্য সেই অঙ্গভঙ্গিটিকে বিশেষভাবে ওভাররাইড করে ।

আপনার অ্যাপটিকে অঙ্গভঙ্গি নেভিগেশনের সাথে সামঞ্জস্যপূর্ণ করতে, আপনি অ্যাপের বিষয়বস্তুকে প্রান্ত থেকে প্রান্তে প্রসারিত করতে এবং বিরোধপূর্ণ অঙ্গভঙ্গিগুলি যথাযথভাবে পরিচালনা করতে চাইবেন৷ তথ্যের জন্য, অঙ্গভঙ্গি নেভিগেশন ডকুমেন্টেশন দেখুন।

এনডিকে

Android 10 নিম্নলিখিত NDK পরিবর্তনগুলি অন্তর্ভুক্ত করে।

ভাগ করা বস্তুতে পাঠ্য স্থানান্তর থাকতে পারে না

Android 6.0 (API লেভেল 23) শেয়ার করা অবজেক্টে টেক্সট রিলোকেশনের ব্যবহার অননুমোদিত । কোড যেমন আছে তেমন লোড করা উচিত এবং সংশোধন করা উচিত নয়। এই পরিবর্তন অ্যাপ লোডের সময় এবং নিরাপত্তা উন্নত করে।

SELinux এই বিধিনিষেধ প্রয়োগ করে Android 10 বা উচ্চতর অ্যাপের উপর। যদি এই অ্যাপগুলি শেয়ার করা অবজেক্টগুলি ব্যবহার করা চালিয়ে যায় যাতে পাঠ্য স্থানান্তর থাকে তবে সেগুলি ভেঙে যাওয়ার উচ্চ ঝুঁকিতে রয়েছে৷

বায়োনিক লাইব্রেরি এবং ডায়নামিক লিঙ্কার পাথের পরিবর্তন

অ্যান্ড্রয়েড 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/… পাথ যোগ করা উচিত।

সিস্টেম বাইনারি/লাইব্রেরি শুধুমাত্র এক্সিকিউট মেমরিতে ম্যাপ করা হয়েছে

অ্যান্ড্রয়েড 10 থেকে শুরু করে, কোড-পুনঃব্যবহারের আক্রমণের বিরুদ্ধে কঠোর কৌশল হিসাবে সিস্টেম বাইনারি এবং লাইব্রেরির এক্সিকিউটেবল সেগমেন্টগুলি মেমরি এক্সিকিউট-অনলি (পঠনযোগ্য নয়) এ ম্যাপ করা হয়েছে। যদি আপনার অ্যাপ শুধুমাত্র এক্সিকিউট হিসেবে চিহ্নিত মেমরি সেগমেন্টে রিড অপারেশন করে থাকে - বাগ, দুর্বলতা বা ইচ্ছাকৃত মেমরি পরিদর্শন থেকে হোক - সিস্টেমটি আপনার অ্যাপে একটি SIGSEGV সংকেত পাঠাবে।

আপনি /data/tombstones/ এ সম্পর্কিত tombstone ফাইলটি পরীক্ষা করে এই আচরণটি ক্র্যাশ করেছে কিনা তা সনাক্ত করতে পারেন। একটি এক্সিকিউট-ওনলি সম্পর্কিত ক্র্যাশে নিম্নলিখিত ত্যাগ বার্তা রয়েছে:

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

মেমরি পরিদর্শনের মতো ক্রিয়াকলাপগুলি সম্পাদন করার জন্য এই সমস্যাটি সমাধান করার জন্য, mprotect() কল করে শুধুমাত্র-নির্বাহিত অংশগুলিকে read+execute হিসাবে চিহ্নিত করা সম্ভব। যাইহোক, আমরা দৃঢ়ভাবে এটিকে কেবলমাত্র পরেই এক্সিকিউট করার জন্য সেট করার সুপারিশ করি, কারণ এই অ্যাক্সেস অনুমতি সেটিং আপনার অ্যাপ এবং ব্যবহারকারীদের জন্য আরও ভাল সুরক্ষা প্রদান করে।

নিরাপত্তা

Android 10-এ নিম্নলিখিত নিরাপত্তা পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে৷

TLS 1.3 ডিফল্টরূপে সক্রিয়

অ্যান্ড্রয়েড 10 এবং উচ্চতর, সমস্ত TLS সংযোগের জন্য ডিফল্টরূপে TLS 1.3 সক্ষম করা আছে। এখানে আমাদের TLS 1.3 বাস্তবায়ন সম্পর্কে কয়েকটি গুরুত্বপূর্ণ বিবরণ রয়েছে:

  • TLS 1.3 সাইফার স্যুট কাস্টমাইজ করা যাবে না। সমর্থিত TLS 1.3 সাইফার স্যুটগুলি সর্বদা সক্রিয় থাকে যখন TLS 1.3 সক্ষম থাকে৷ setEnabledCipherSuites() কল করে তাদের নিষ্ক্রিয় করার যেকোনো প্রচেষ্টা উপেক্ষা করা হয়।
  • যখন TLS 1.3 আলোচনা করা হয়, তখন সেশন ক্যাশে সেশন যোগ করার আগে HandshakeCompletedListener অবজেক্টগুলিকে কল করা হয়। (TLS 1.2 এবং অন্যান্য পূর্ববর্তী সংস্করণগুলিতে, সেশন ক্যাশে সেশন যোগ করার পরে এই বস্তুগুলিকে ডাকা হয়।)
  • কিছু পরিস্থিতিতে যেখানে SSLEngine দৃষ্টান্তগুলি Android এর পূর্ববর্তী সংস্করণগুলিতে একটি SSLHandshakeException নিক্ষেপ করে, এই উদাহরণগুলি Android 10 এবং উচ্চতর সংস্করণগুলির পরিবর্তে একটি SSLProtocolException নিক্ষেপ করে৷
  • 0-RTT মোড সমর্থিত নয়।

যদি ইচ্ছা হয়, আপনি SSLContext.getInstance("TLSv1.2") কল করে TLS 1.3 নিষ্ক্রিয় করা একটি SSLContext পেতে পারেন৷ আপনি একটি উপযুক্ত বস্তুতে setEnabledProtocols() কল করে প্রতি-সংযোগের ভিত্তিতে প্রোটোকল সংস্করণগুলি সক্ষম বা নিষ্ক্রিয় করতে পারেন।

SHA-1-এর সাথে স্বাক্ষরিত শংসাপত্রগুলি TLS-এ বিশ্বস্ত নয়৷

Android 10-এ, যে শংসাপত্রগুলি SHA-1 হ্যাশ অ্যালগরিদম ব্যবহার করে সেগুলি TLS সংযোগগুলিতে বিশ্বস্ত নয়৷ Root CA গুলি 2016 সাল থেকে এই জাতীয় শংসাপত্র জারি করেনি এবং তারা আর Chrome বা অন্যান্য প্রধান ব্রাউজারগুলিতে বিশ্বস্ত নয়৷

SHA-1 ব্যবহার করে একটি শংসাপত্র উপস্থাপন করে এমন একটি সাইটে সংযোগ হলে সংযোগ করার কোনো প্রচেষ্টা ব্যর্থ হয়।

কীচেইন আচরণ পরিবর্তন এবং উন্নতি

কিছু ব্রাউজার, যেমন Google Chrome, ব্যবহারকারীদের একটি শংসাপত্র চয়ন করার অনুমতি দেয় যখন একটি TLS সার্ভার একটি TLS হ্যান্ডশেকের অংশ হিসাবে একটি শংসাপত্র অনুরোধ বার্তা পাঠায়। অ্যান্ড্রয়েড 10 অনুসারে, ব্যবহারকারীদের একটি শংসাপত্র নির্বাচন প্রম্পট দেখানোর জন্য KeyChain.choosePrivateKeyAlias() কল করার সময় KeyChain অবজেক্টগুলি ইস্যুকারী এবং মূল স্পেসিফিকেশন প্যারামিটারগুলিকে সম্মান করে৷ বিশেষ করে, এই প্রম্পটে এমন পছন্দ নেই যা সার্ভারের স্পেসিফিকেশন মেনে চলে না।

যদি কোনও ব্যবহারকারী-নির্বাচনযোগ্য শংসাপত্র উপলব্ধ না থাকে, যেমন কোনও শংসাপত্র সার্ভারের স্পেসিফিকেশনের সাথে মেলে বা কোনও ডিভাইসে কোনও শংসাপত্র ইনস্টল না থাকলে, শংসাপত্র নির্বাচন প্রম্পটটি মোটেও উপস্থিত হয় না।

উপরন্তু, একটি KeyChain অবজেক্টে কী বা CA শংসাপত্রগুলি আমদানি করতে 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 রিকোয়েস্টে সমর্থিত_স্বাক্ষর_অ্যালগরিদম এক্সটেনশনটি শংসাপত্রের প্রতিক্রিয়াগুলির জন্য একটি স্বাক্ষর কী নির্বাচন করার সময় সম্মান করা হয়।
  • অস্বচ্ছ সাইনিং কী, যেমন Android কীস্টোর থেকে, TLS-এ RSA-PSS স্বাক্ষরের সাথে ব্যবহার করা যেতে পারে।

Wi-Fi সরাসরি সম্প্রচার

অ্যান্ড্রয়েড 10-এ, Wi-Fi ডাইরেক্ট সম্পর্কিত নিম্নলিখিত সম্প্রচারগুলি স্টিকি নয়:

যদি আপনার অ্যাপটি রেজিস্ট্রেশনের সময় এই সম্প্রচারগুলি পাওয়ার উপর নির্ভর করে কারণ সেগুলি স্টিকি ছিল, তবে পরিবর্তে তথ্যটি পেতে প্রারম্ভে উপযুক্ত get() পদ্ধতি ব্যবহার করুন।

ওয়াই-ফাই সচেতন ক্ষমতা

Android 10 Wi-Fi সচেতন ডেটাপথ ব্যবহার করে TCP/UDP সকেট তৈরিকে সহজ করার জন্য সমর্থন যোগ করে। ServerSocket সাথে সংযোগকারী একটি TCP/UDP সকেট তৈরি করতে, ক্লায়েন্ট ডিভাইসটিকে সার্ভারের IPv6 ঠিকানা এবং পোর্ট জানতে হবে। এটির আগে ব্যান্ডের বাইরে যোগাযোগ করা দরকার ছিল, যেমন BT বা Wi-Fi Aware লেয়ার 2 মেসেজিং ব্যবহার করে, অথবা mDNS-এর মতো অন্যান্য প্রোটোকল ব্যবহার করে ইন-ব্যান্ড আবিষ্কার করা হয়েছিল। অ্যান্ড্রয়েড 10 এর সাথে, নেটওয়ার্ক সেটআপের অংশ হিসাবে তথ্য যোগাযোগ করা যেতে পারে।

সার্ভার নিম্নলিখিত যে কোনো একটি করতে পারে:

  • একটি ServerSocket শুরু করুন এবং ব্যবহার করার জন্য পোর্ট সেট করুন বা প্রাপ্ত করুন।
  • Wi-Fi সচেতন নেটওয়ার্ক অনুরোধের অংশ হিসাবে পোর্ট তথ্য নির্দিষ্ট করুন।

নিম্নলিখিত কোড নমুনা দেখায় কিভাবে নেটওয়ার্ক অনুরোধের অংশ হিসাবে পোর্ট তথ্য নির্দিষ্ট করতে হয়:

কোটলিন 

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

ক্লায়েন্ট তারপর IPv6 এবং সার্ভার দ্বারা সরবরাহিত পোর্ট পেতে একটি Wi-Fi সচেতন নেটওয়ার্ক অনুরোধ সম্পাদন করে:

কোটলিন 

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 অনুমতি গ্রহণ করতে পারে না। এর কারণ হল ওভারলে উইন্ডোগুলি আঁকার সময় অতিরিক্ত মেমরি ব্যবহার করা হয়, যা বিশেষত কম মেমরির অ্যান্ড্রয়েড ডিভাইসগুলির কার্যকারিতার জন্য ক্ষতিকারক৷

অ্যান্ড্রয়েড 9 বা তার নিচের সংস্করণে চলমান একটি Go সংস্করণ ডিভাইসে চলমান কোনো অ্যাপ যদি SYSTEM_ALERT_WINDOW অনুমতি পায়, তাহলে ডিভাইসটি Android 10-এ আপগ্রেড করা হলেও অ্যাপটি সেই অনুমতি ধরে রাখে। তবে, যে অ্যাপগুলির কাছে ইতিমধ্যেই সেই অনুমতি নেই সেগুলিকে অনুমতি দেওয়া যাবে না ডিভাইস আপগ্রেড করা হয়।

যদি একটি Go ডিভাইসে একটি অ্যাপ ACTION_MANAGE_OVERLAY_PERMISSION ক্রিয়া সহ একটি অভিপ্রায় পাঠায়, সিস্টেম স্বয়ংক্রিয়ভাবে অনুরোধটি অস্বীকার করে এবং ব্যবহারকারীকে একটি সেটিংস স্ক্রিনে নিয়ে যায় যা বলে যে অনুমতিটি অনুমোদিত নয় কারণ এটি ডিভাইসটিকে ধীর করে দেয়৷ যদি একটি Go ডিভাইসে একটি অ্যাপ Settings.canDrawOverlays() কল করে, তবে পদ্ধতিটি সর্বদা মিথ্যা ফেরত দেয়। আবার, ডিভাইসটিকে Android 10 এ আপগ্রেড করার আগে SYSTEM_ALERT_WINDOW অনুমতি পাওয়া অ্যাপগুলির ক্ষেত্রে এই বিধিনিষেধগুলি প্রযোজ্য নয়৷

পুরানো Android সংস্করণগুলিকে লক্ষ্য করে এমন অ্যাপগুলির জন্য সতর্কতা৷

অ্যান্ড্রয়েড 10 বা উচ্চতর সংস্করণে চালিত ডিভাইসগুলি ব্যবহারকারীদের প্রথমবার সতর্ক করে যে তারা Android 5.1 (API লেভেল 22) বা তার নিচের কোনো অ্যাপ চালালে। অ্যাপটির ব্যবহারকারীকে অনুমতি দেওয়ার প্রয়োজন হলে, অ্যাপটিকে প্রথমবার চালানোর অনুমতি দেওয়ার আগে ব্যবহারকারীকে অ্যাপের অনুমতিগুলি সামঞ্জস্য করার সুযোগ দেওয়া হয়।

Google Play-এর টার্গেট API প্রয়োজনীয়তার কারণে, একজন ব্যবহারকারী শুধুমাত্র তখনই এই সতর্কতাগুলি দেখতে পান যখন তারা এমন একটি অ্যাপ চালান যা সম্প্রতি আপডেট করা হয়নি। অন্যান্য স্টোরের মাধ্যমে বিতরণ করা অ্যাপগুলির জন্য, অনুরূপ লক্ষ্য API প্রয়োজনীয়তাগুলি 2019 সালে কার্যকর হচ্ছে৷ এই প্রয়োজনীয়তাগুলি সম্পর্কে আরও তথ্যের জন্য, 2019-এ লক্ষ্য API স্তরের প্রয়োজনীয়তা প্রসারিত করা দেখুন৷

SHA-2 CBC সাইফার স্যুটগুলি সরানো হয়েছে৷

নিম্নলিখিত 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 এবং CBC ভেরিয়েন্টকে সমর্থন করে বা তাদের কোনোটিকেই সমর্থন করে না।

অ্যাপ ব্যবহার

অ্যান্ড্রয়েড 10 অ্যাপ ব্যবহারের সাথে সম্পর্কিত নিম্নলিখিত আচরণ পরিবর্তনগুলি প্রবর্তন করে:

  • UsageStats অ্যাপ ব্যবহারের উন্নতি - যখন অ্যাপগুলি স্প্লিট-স্ক্রিন বা পিকচার-ইন-পিকচার মোডে ব্যবহার করা হয় তখন Android 10 সঠিকভাবে UsageStats-এর সাহায্যে অ্যাপের ব্যবহার ট্র্যাক করে। উপরন্তু, Android 10 সঠিকভাবে তাত্ক্ষণিক অ্যাপ ব্যবহার ট্র্যাক করে।

  • প্রতি-অ্যাপ গ্রেস্কেল - Android 10 প্রতি-অ্যাপ ভিত্তিতে একটি গ্রেস্কেল ডিসপ্লে মোড সেট করতে পারে।

  • প্রতি-অ্যাপ বিক্ষেপ অবস্থা - Android 10 অ্যাপগুলিকে বেছে বেছে একটি "বিক্ষেপণ অবস্থায়" সেট করতে পারে যেখানে তাদের বিজ্ঞপ্তিগুলি চাপা থাকে এবং সেগুলি প্রস্তাবিত অ্যাপ হিসাবে প্রদর্শিত হয় না।

  • সাসপেনশন এবং প্লেব্যাক - Android 10 এ, সাসপেন্ড করা অ্যাপগুলি অডিও চালাতে সক্ষম নয়।

HTTPS সংযোগ পরিবর্তন

যদি Android 10 চালিত একটি অ্যাপ setSSLSocketFactory() এ null পাস করে, তাহলে একটি IllegalArgumentException ঘটে। পূর্ববর্তী সংস্করণগুলিতে, null setSSLSocketFactory() এ পাস করা বর্তমান ডিফল্ট কারখানায় পাস করার মতো একই প্রভাব ফেলে।

android.preference লাইব্রেরি বাতিল করা হয়েছে

android.preference লাইব্রেরিটি Android 10-এর হিসাবে বাতিল করা হয়েছে৷ বিকাশকারীদের পরিবর্তে Android Jetpack- এর অংশ, AndroidX পছন্দ লাইব্রেরি ব্যবহার করা উচিত৷ মাইগ্রেশন এবং উন্নয়নে সহায়তা করার জন্য অতিরিক্ত সংস্থানগুলির জন্য, আমাদের সর্বজনীন নমুনা অ্যাপ এবং রেফারেন্স ডকুমেন্টেশন সহ আপডেট করা সেটিংস গাইড দেখুন।

ZIP ফাইল ইউটিলিটি লাইব্রেরি পরিবর্তন

Android 10 java.util.zip প্যাকেজের ক্লাসগুলিতে নিম্নলিখিত পরিবর্তনগুলি প্রবর্তন করে, যা ZIP ফাইলগুলি পরিচালনা করে৷ এই পরিবর্তনগুলি Android এবং java.util.zip ব্যবহার করে এমন অন্যান্য প্ল্যাটফর্মগুলির মধ্যে লাইব্রেরির আচরণকে আরও সামঞ্জস্যপূর্ণ করে তোলে।

Inflater

পূর্ববর্তী সংস্করণগুলিতে, Inflater ক্লাসের কিছু পদ্ধতি একটি IllegalStateException নিক্ষেপ করে যদি সেগুলি একটি কল to end() পরে আহ্বান করা হয়। অ্যান্ড্রয়েড 10-এ, এই পদ্ধতিগুলি পরিবর্তে একটি NullPointerException নিক্ষেপ করে।

জিপফাইল

Android 10 এবং উচ্চতর ক্ষেত্রে, ZipFile এর কনস্ট্রাক্টর যেটি File , int , এবং Charset টাইপের আর্গুমেন্ট নেয়, যদি সরবরাহ করা ZIP ফাইলে কোনো ফাইল না থাকে তাহলে সেটি ZipException দেয় না।

জিপআউটপুট স্ট্রিম

অ্যান্ড্রয়েড 10 এবং উচ্চতর ক্ষেত্রে, ZipOutputStream এর finish() পদ্ধতিটি ZipException থ্রো করে না যদি এটি একটি জিপ ফাইলের জন্য একটি আউটপুট স্ট্রীম লেখার চেষ্টা করে যাতে কোনো ফাইল নেই।

ক্যামেরা পরিবর্তন

অনেক ক্যামেরা-ব্যবহারকারী অ্যাপ অনুমান করে যে ডিভাইসটি যদি পোর্ট্রেট কনফিগারেশনে থাকে, তাহলে ফিজিক্যাল ডিভাইসটিও পোর্ট্রেট ওরিয়েন্টেশনে থাকে, যেমন ক্যামেরা ওরিয়েন্টেশনে বর্ণনা করা হয়েছে। এটি অতীতে একটি নিরাপদ অনুমান ছিল, তবে এটি ভাঁজযোগ্যগুলির মতো উপলব্ধ ফর্ম ফ্যাক্টরগুলির প্রসারণের সাথে পরিবর্তিত হয়েছে। এই ডিভাইসগুলিতে অনুমানটি ক্যামেরা ভিউফাইন্ডারের ভুলভাবে ঘোরানো বা স্কেল করা (বা উভয়) প্রদর্শনের দিকে নিয়ে যেতে পারে।

API স্তর 24 বা তার উপরে লক্ষ্য করে এমন অ্যাপ্লিকেশনগুলিকে স্পষ্টভাবে android:resizeableActivity সেট করা উচিত এবং মাল্টি-উইন্ডো অপারেশন পরিচালনা করার জন্য প্রয়োজনীয় কার্যকারিতা প্রদান করা উচিত।

ব্যাটারি ব্যবহার ট্র্যাকিং

Android 10 দিয়ে শুরু করে, SystemHealthManager যখনই একটি বড় চার্জিং ইভেন্টের পরে ডিভাইসটি আনপ্লাগ করা হয় তখন ব্যাটারি ব্যবহারের পরিসংখ্যান পুনরায় সেট করে৷ বিস্তৃতভাবে বলতে গেলে, একটি প্রধান চার্জিং ইভেন্ট হল: ডিভাইসটি সম্পূর্ণভাবে চার্জ করা হয়েছে, অথবা ডিভাইসটি বেশিরভাগ চার্জ হয়ে গেছে।

অ্যান্ড্রয়েড 10-এর আগে, যখনই ডিভাইসটি আনপ্লাগ করা হয়েছিল তখন ব্যাটারি ব্যবহারের পরিসংখ্যান রিসেট হত, ব্যাটারি স্তরে যতই সামান্য পরিবর্তন হোক না কেন।

অ্যান্ড্রয়েড বিম অবচয়

অ্যান্ড্রয়েড 10-এ আমরা আনুষ্ঠানিকভাবে অ্যান্ড্রয়েড বিমকে বাতিল করছি, নিয়ার ফিল্ড কমিউনিকেশন (NFC) এর মাধ্যমে ডিভাইস জুড়ে ডেটা ভাগ করে নেওয়ার জন্য একটি পুরানো বৈশিষ্ট্য। আমরা বেশ কিছু সম্পর্কিত NFC API-কে অবমূল্যায়ন করছি। অ্যান্ড্রয়েড বিম ঐচ্ছিকভাবে ডিভাইস প্রস্তুতকারক অংশীদারদের জন্য উপলব্ধ থাকে যারা এটি ব্যবহার করতে চান, কিন্তু এটি আর সক্রিয় বিকাশে নেই। অ্যান্ড্রয়েড অন্যান্য এনএফসি ক্ষমতা এবং এপিআই সমর্থন করা অব্যাহত রাখবে, এবং ট্যাগ থেকে পড়া এবং অর্থপ্রদানের মতো ব্যবহারের ক্ষেত্রে প্রত্যাশিতভাবে কাজ করতে থাকবে।

java.math.BigDecimal.stripTrailingZeros() আচরণ পরিবর্তন

BigDecimal.stripTrailingZeros() ইনপুট মান শূন্য হলে বিশেষ ক্ষেত্রে ট্রেলিং জিরোগুলি আর সংরক্ষণ করে না।

java.util.regex.Matcher এবং প্যাটার্ন আচরণ পরিবর্তন

যখন ইনপুটের শুরুতে একটি শূন্য-প্রস্থ মিল থাকে তখন split() এর ফলাফলটি একটি খালি String ("") দিয়ে আর শুরু না করতে পরিবর্তিত হয়। এটি String.split() কেও প্রভাবিত করে। উদাহরণস্বরূপ, "x".split("") এখন {"x"} রিটার্ন করে যেখানে এটি Android এর পুরানো ভার্সনে {"", "x"} রিটার্ন করত। "aardvark".split("(?=a)" এখন {""", " {"", "a", "ardv", "ark"} {"a", "ardv", "ark"} ", "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-এ, আপনি যদি XML-এ একটি GradientDrawable সংজ্ঞায়িত করেন এবং একটি কোণ পরিমাপ প্রদান না করেন, তাহলে গ্রেডিয়েন্ট অরিয়েন্টেশনটি TOP_BOTTOM এ ডিফল্ট হয়। এটি Android এর পূর্ববর্তী সংস্করণ থেকে একটি পরিবর্তন, যেখানে ডিফল্ট ছিল LEFT_RIGHT ।

একটি সমাধান হিসাবে, আপনি যদি AAPT2 এর সাম্প্রতিকতম সংস্করণে আপডেট করেন, কোন কোণ পরিমাপ নির্দিষ্ট না থাকলে টুলটি লিগ্যাসি অ্যাপগুলির জন্য 0 এর একটি কোণ পরিমাপ সেট করে৷

ডিফল্ট SUID ব্যবহার করে ক্রমিক বস্তুর জন্য লগিং করা

অ্যান্ড্রয়েড 7.0 (এপিআই স্তর 24) দিয়ে শুরু করে, প্ল্যাটফর্মটি সিরিয়ালাইজেবল অবজেক্টের জন্য ডিফল্ট serialVersionUID ইউআইডিতে একটি সংশোধন করেছে। এই ফিক্সটি API স্তর 23 বা তার নিচের টার্গেট করা অ্যাপগুলিকে প্রভাবিত করেনি।

অ্যান্ড্রয়েড 10 থেকে শুরু করে, যদি কোনো অ্যাপ এপিআই লেভেল 23 বা তার নিচের দিকে লক্ষ্য করে এবং পুরানো, ভুল, ডিফল্ট serialVersionUID উপর নির্ভর করে, সিস্টেমটি একটি সতর্কতা লগ করে এবং একটি কোড ফিক্স করার পরামর্শ দেয়।

বিশেষত, সিস্টেমটি একটি সতর্কতা লগ করে যদি নিচের সবগুলো সত্য হয়:

  • অ্যাপটি এপিআই লেভেল 23 বা তার কম লক্ষ্য করে।
  • একটি ক্লাস সিরিয়াল করা হয়।
  • সিরিয়ালাইজড ক্লাসটি ডিফল্ট serialVersionUID ব্যবহার করে, এর পরিবর্তে স্পষ্টভাবে একটি serialVersionUID সেট করা হয়।
  • ডিফল্ট serialVersionUID serialVersionUID থেকে আলাদা যদি অ্যাপটি API লেভেল 24 বা তার বেশি টার্গেট করে।

এই সতর্কতা প্রতিটি প্রভাবিত শ্রেণীর জন্য একবার লগ করা হয়. সতর্কীকরণ বার্তাটিতে একটি প্রস্তাবিত সংশোধন অন্তর্ভুক্ত রয়েছে, যা স্পষ্টভাবে serialVersionUID ডিফল্ট মানতে সেট করতে হবে যা অ্যাপটি লক্ষ্য করা API স্তর 24 বা তার বেশি হলে গণনা করা হবে। সেই ফিক্সটি ব্যবহার করে, আপনি নিশ্চিত করতে পারেন যে যদি সেই ক্লাসের একটি অবজেক্টকে এমন একটি অ্যাপে সিরিয়াল করা হয় যা এপিআই লেভেল 23 বা তার নিচের টার্গেট করে, তাহলে অবজেক্টটি 24 বা তার বেশি টার্গেট করা অ্যাপ দ্বারা সঠিকভাবে পড়া হবে এবং এর বিপরীতে।

java.io.FileChannel.map() পরিবর্তন

Android 10 থেকে শুরু করে, FileChannel.map() অ-মানক ফাইলগুলির জন্য সমর্থিত নয়, যেমন /dev/zero , যার আকার truncate() ব্যবহার করে পরিবর্তন করা যাবে না। অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলি truncate() দ্বারা প্রত্যাবর্তিত ত্রুটিটি গ্রাস করেছে, কিন্তু Android 10 একটি IOException নিক্ষেপ করেছে। আপনার যদি পুরানো আচরণের প্রয়োজন হয় তবে আপনাকে অবশ্যই নেটিভ কোড ব্যবহার করতে হবে।