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

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

আপনার অ্যাপের targetSdkVersion 29 বা তার বেশি হলে, আপনাকে অতিরিক্ত পরিবর্তনও সাপোর্ট করতে হবে। বিস্তারিত জানতে টার্গেট 29-এর জন্য অ্যাপের আচরণে পরিবর্তন পড়তে ভুলবেন না।

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

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

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

SDK-নয় এমন ইন্টারফেস সংক্রান্ত বিধিনিষেধ

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

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

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

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

জেসচার নেভিগেশন

Android ১০ থেকে শুরু করে, ব্যবহারকারীরা ডিভাইস জুড়ে জেসচার নেভিগেশন চালু করতে পারবেন। কোনও ব্যবহারকারী জেসচার নেভিগেশন চালু করলে, এটি ডিভাইসের সব অ্যাপকে প্রভাবিত করে, অ্যাপটি API লেভেল ২৯ টার্গেট করুক বা না করুক। যেমন, ব্যবহারকারী স্ক্রিনের প্রান্ত থেকে ভিতরের দিকে সোয়াইপ করলে, সিস্টেম সেই জেসচারকে ব্যাক নেভিগেশন হিসেবে ব্যাখ্যা করে, যদি না কোনও অ্যাপ স্ক্রিনের কিছু অংশের জন্য বিশেষভাবে সেই জেসচার ওভাররাইড করে।

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

NDK

Android ১০-এ নিম্নলিখিত NDK পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে।

শেয়ার করা অবজেক্টে টেক্সট রিলোকেশন থাকতে পারবে না

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

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

Bionic লাইব্রেরি ও ডায়নামিক লিঙ্কার পাথে পরিবর্তন

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

এই পরিবর্তনগুলি ফাইলের ৬৪-বিট ভেরিয়েন্টের ক্ষেত্রেও প্রযোজ্য, যেখানে 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 ১০ থেকে শুরু করে, সিস্টেম বাইনারি এবং লাইব্রেরির এক্সিকিউটেবল সেগমেন্টগুলি কোড-রিইউজ অ্যাটাকের বিরুদ্ধে একটি হার্ডেনিং টেকনিক হিসেবে মেমরি এক্সিকিউট-অনলি (পড়া যায় না) হিসেবে ম্যাপ করা হয়। আপনার অ্যাপ যদি শুধুমাত্র-এক্সিকিউট হিসেবে চিহ্নিত মেমরি সেগমেন্টে রিড অপারেশন করে – তা বাগ, দুর্বলতা বা ইচ্ছাকৃত মেমরি পরিদর্শনের কারণে হোক না কেন – সিস্টেম আপনার অ্যাপে একটি SIGSEGV সিগন্যাল পাঠায়।

এই আচরণের কারণে ক্র্যাশ হয়েছে কিনা তা আপনি /data/tombstones/-এ সংশ্লিষ্ট টুম্বস্টোন ফাইল পরীক্ষা করে শনাক্ত করতে পারবেন। শুধুমাত্র-এক্সিকিউট সংক্রান্ত ক্র্যাশ নিম্নলিখিত অ্যাবর্ট মেসেজ ধারণ করে:

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

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

নিরাপত্তা

Android 10-এ নিরাপত্তা সংক্রান্ত নিম্নলিখিত পরিবর্তন করা হয়েছে।

TLS 1.3 ডিফল্ট হিসেবে চালু করা আছে

Android 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 কানেকশনে বিশ্বস্ত নয়। ২০১৬ সাল থেকে রুট CA এই ধরনের সার্টিফিকেট ইস্যু করেনি এবং Chrome বা অন্যান্য প্রধান ব্রাউজারে এগুলি আর বিশ্বস্ত নয়।

SHA-1 ব্যবহার করে সার্টিফিকেট দেখায় এমন সাইটের সাথে কানেক্ট করার চেষ্টা করলে, কানেক্ট করা যাবে না।

KeyChain-এর আচরণে পরিবর্তন ও উন্নতি

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

ব্যবহারকারী বেছে নিতে পারেন এমন কোনও সার্টিফিকেট উপলভ্য না থাকলে, যেমন কোনও সার্টিফিকেট সার্ভারের স্পেসিফিকেশনের সাথে না মিললে অথবা ডিভাইসে কোনও সার্টিফিকেট ইনস্টল করা না থাকলে, সার্টিফিকেট বেছে নেওয়ার প্রম্পট একেবারেই দেখা যায় না।

এছাড়াও, Android ১০ বা তার পরবর্তী ভার্সনে KeyChain অবজেক্টে কী বা CA সার্টিফিকেট ইমপোর্ট করার জন্য ডিভাইস স্ক্রিন লক থাকা আবশ্যক নয়।

অন্যান্য TLS ও ক্রিপ্টোগ্রাফি সংক্রান্ত পরিবর্তন

TLS এবং ক্রিপ্টোগ্রাফি লাইব্রেরিতে বেশ কিছু ছোটখাটো পরিবর্তন করা হয়েছে যা Android 10-এ কার্যকর হয়:

  • AES/GCM/NoPadding এবং ChaCha20/Poly1305/NoPadding সাইফার getOutputSize() থেকে আরও সঠিক বাফার সাইজ রিটার্ন করে।
  • TLS 1.2 বা তার থেকে বেশি ভার্সনের প্রোটোকল ব্যবহার করে কানেক্ট করার চেষ্টা করা হলে, TLS_FALLBACK_SCSV সাইফার স্যুট বাদ দেওয়া হয়। TLS সার্ভার ইমপ্লিমেন্টেশনে উন্নতির কারণে, আমরা TLS-এক্সটার্নাল ফলব্যাক চেষ্টা করার সাজেশন দিই না। পরিবর্তে, আমরা TLS ভার্সন নেগোসিয়েশনের উপর নির্ভর করার সাজেশন দিই।
  • ChaCha20-Poly1305 হল ChaCha20/Poly1305/NoPadding-এর একটি উপনাম।
  • ট্রেলিং ডট সহ হোস্টনেমকে সঠিক SNI হোস্টনেম হিসেবে বিবেচনা করা হয় না।
  • সার্টিফিকেট উত্তরের জন্য সাইনিং কী বেছে নেওয়ার সময় CertificateRequest-এ supported_signature_algorithms এক্সটেনশন ব্যবহার করা হয়।
  • Android Keystore-এর মতো অস্বচ্ছ সাইনিং কী, TLS-এ RSA-PSS স্বাক্ষরের সাথে ব্যবহার করা যেতে পারে।

Wi-Fi Direct ব্রডকাস্ট

Android 10-এ, Wi-Fi Direct-এর সাথে সম্পর্কিত নিম্নলিখিত ব্রডকাস্ট স্টিকি নয়:

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

Wi-Fi Aware-এর ক্ষমতা

Android 10-এ Wi-Fi Aware ডেটাপাথ ব্যবহার করে TCP/UDP সকেট তৈরি করার সুবিধা যোগ করা হয়েছে। ServerSocket-এর সাথে কানেক্ট করা TCP/UDP সকেট তৈরি করতে, ক্লায়েন্ট ডিভাইসকে সার্ভারের IPv6 অ্যাড্রেস ও পোর্ট জানতে হবে। আগে এটি আউট-অফ-ব্যান্ডের মাধ্যমে কমিউনিকেট করতে হত, যেমন BT বা Wi-Fi Aware লেয়ার ২ মেসেজিং ব্যবহার করে অথবা mDNS-এর মতো অন্যান্য প্রোটোকল ব্যবহার করে ইন-ব্যান্ডে খুঁজে নিতে হত। Android ১০-এর ক্ষেত্রে, নেটওয়ার্ক সেট-আপের অংশ হিসেবে তথ্য কমিউনিকেট করা যেতে পারে।

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

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

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

Kotlin

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

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

জাভা

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

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

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

Kotlin

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

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

connMgr.requestNetwork(networkRequest, callback)

জাভা

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 ১০ (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 (API লেভেল 22) বা তার আগের যেকোনও ভার্সনকে টার্গেট করে এমন কোনও অ্যাপ প্রথমবার চালানোর সময় ব্যবহারকারীকে সতর্ক করা হয়। অ্যাপটি ব্যবহারকারীর থেকে অনুমতি চাইলে, প্রথমবার অ্যাপটি চালানোর অনুমতি দেওয়ার আগে ব্যবহারকারীকে অ্যাপের অনুমতি অ্যাডজাস্ট করার সুযোগও দেওয়া হয়।

Google Play-এর টার্গেট API প্রয়োজনীয়তার কারণে, কোনও ব্যবহারকারী সম্প্রতি আপডেট করা হয়নি এমন অ্যাপ চালালে তবেই এই ধরনের সতর্কতা দেখতে পান। অন্যান্য স্টোরের মাধ্যমে ডিস্ট্রিবিউট করা অ্যাপের ক্ষেত্রে, ২০১৯ সাল থেকে একই ধরনের টার্গেট API প্রয়োজনীয়তা কার্যকর করা হচ্ছে। এইসব প্রয়োজনীয়তা সম্পর্কে আরও জানতে, ২০১৯-এ টার্গেট 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 উভয় ভেরিয়েন্টকেই সমর্থন করে অথবা তাদের কোনোটিকেই সমর্থন করে না।

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

Android 10-এ অ্যাপ ব্যবহার সংক্রান্ত নিম্নলিখিত আচরণগত পরিবর্তন করা হয়েছে:

  • UsageStats অ্যাপের ব্যবহার সংক্রান্ত উন্নতি - স্প্লিট-স্ক্রিন বা ছবির-মধ্যে-ছবি মোডে অ্যাপ ব্যবহার করা হলে, Android ১০ UsageStats-এর মাধ্যমে অ্যাপের ব্যবহার সঠিকভাবে ট্র্যাক করে। এছাড়াও, Android ১০ ইনস্ট্যান্ট অ্যাপের ব্যবহার সঠিকভাবে ট্র্যাক করে।

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

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

  • সাসপেনশন ও প্লেব্যাক - Android ১০-এ সাসপেন্ডেড অ্যাপ অডিও চালাতে পারে না।

HTTPS কানেকশনে পরিবর্তন

Android ১০-এ চলা কোনও অ্যাপ যদি null-কে setSSLSocketFactory()-এ পাস করে, তাহলে IllegalArgumentException হয়। আগের ভার্সনে, null-কে setSSLSocketFactory()-এ পাস করার প্রভাব বর্তমান ডিফল্ট ফ্যাক্টরি-তে পাস করার মতোই ছিল।

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

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

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

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

ইনফ্লেটার

আগের ভার্সনে, Inflater ক্লাসের কিছু পদ্ধতি end()-এ কল করার পরে ইনভোক করা হলে IllegalStateException থ্রো করত। Android 10-এ, এই পদ্ধতিগুলি পরিবর্তে একটি NullPointerException থ্রো করে।

ZipFile

Android 10 ও তার পরবর্তী ভার্সনে, কনস্ট্রাক্টর ZipFile যা File, int ও Charset ধরনের আর্গুমেন্ট নেয়, সেটি ZipException থ্রো করে না যদি প্রদত্ত ZIP ফাইলে কোনও ফাইল না থাকে।

ZipOutputStream

Android ১০ ও তার পরবর্তী ভার্সনে, ZipOutputStream-এ finish() পদ্ধতি ZipException থ্রো করে না, যদি এটি এমন কোনও ZIP ফাইলের জন্য আউটপুট স্ট্রিম লেখার চেষ্টা করে যাতে কোনও ফাইল নেই।

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

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

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

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

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

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

Android Beam বন্ধ হয়ে যাওয়া

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

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"} রিটার্ন করে।

ভুল আর্গুমেন্টের জন্য ব্যতিক্রমী আচরণও উন্নত করা হয়েছে:

  • appendReplacement(StringBuffer, String) এখন IndexOutOfBoundsException-এর পরিবর্তে IllegalArgumentException থ্রো করে যদি পরিবর্তিত String-এর শেষে একটি ব্যাকস্ল্যাশ থাকে, যা অবৈধ। এখন একই ব্যতিক্রম থ্রো করা হয় যদি রিপ্লেসমেন্ট String, $ দিয়ে শেষ হয়। আগে, এই পরিস্থিতিতে কোনও ব্যতিক্রম থ্রো করা হয়নি।
  • replaceFirst(null) আর reset()-কে Matcher-এ কল করে না যদি এটি একটি 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 ব্যবহার করে সিরিয়ালাইজ করা অবজেক্টের জন্য লগিং

Android 7.0 (API লেভেল ২৪) থেকে শুরু করে, প্ল্যাটফর্মটি সিরিয়ালাইজেবল অবজেক্টের জন্য ডিফল্ট serialVersionUID-এ একটি সমাধান করেছে। এই সমাধান API লেভেল ২৩ বা তার কম টার্গেট করা অ্যাপকে প্রভাবিত করেনি।

Android 10 থেকে শুরু করে, কোনও অ্যাপ API লেভেল ২৩ বা তার কম টার্গেট করলে এবং পুরনো, ভুল, ডিফল্ট serialVersionUID-এর উপর নির্ভর করলে, সিস্টেম একটি সতর্কবার্তা লগ করে এবং কোড ঠিক করার সাজেশন দেয়।

বিশেষ করে, নিম্নলিখিত সবকটি শর্ত পূরণ হলে সিস্টেম একটি সতর্কতা লগ করে:

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

প্রতিটি প্রভাবিত ক্লাসের জন্য এই সতর্কতা একবার লগ করা হয়। সতর্কতা মেসেজে একটি সাজেস্ট করা সমাধান অন্তর্ভুক্ত থাকে, যা হল স্পষ্টভাবে serialVersionUID-কে ডিফল্ট ভ্যালুতে সেট করা, যা অ্যাপটি API লেভেল ২৪ বা তার বেশি টার্গেট করলে হিসাব করা হবে। এই সমাধান ব্যবহার করে আপনি নিশ্চিত করতে পারবেন যে, যদি সেই ক্লাসের কোনও অবজেক্ট এমন কোনও অ্যাপে সিরিয়ালাইজ করা হয় যা API লেভেল ২৩ বা তার কম ভার্সনকে টার্গেট করে, তাহলে অবজেক্টটি ২৪ বা তার বেশি ভার্সনকে টার্গেট করা অ্যাপের মাধ্যমে সঠিকভাবে পড়া যাবে, এবং এর উল্টোটাও হবে।

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

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