পূর্ববর্তী রিলিজগুলোর মতোই, অ্যান্ড্রয়েড ১৭-এ এমন কিছু আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণগত পরিবর্তনগুলো শুধুমাত্র সেইসব অ্যাপের জন্য প্রযোজ্য যেগুলো অ্যান্ড্রয়েড ১৭ বা তার উচ্চতর সংস্করণকে টার্গেট করে তৈরি। যদি আপনার অ্যাপটি অ্যান্ড্রয়েড ১৭ বা তার উচ্চতর সংস্করণকে টার্গেট করে তৈরি হয়, তবে প্রযোজ্য ক্ষেত্রে এই আচরণগুলো সমর্থন করার জন্য আপনার অ্যাপটি পরিবর্তন করা উচিত।
আপনার অ্যাপের targetSdkVersion নির্বিশেষে Android 17-এ চলমান সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।
মূল কার্যকারিতা
অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত রয়েছে, যা অ্যান্ড্রয়েড সিস্টেমের বিভিন্ন মূল সক্ষমতাকে সংশোধন বা প্রসারিত করে।
MessageQueue-এর নতুন লক-মুক্ত বাস্তবায়ন
অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করা অ্যাপগুলো android.os.MessageQueue এর একটি নতুন লক-ফ্রি ইমপ্লিমেন্টেশন পাবে। এই নতুন ইমপ্লিমেন্টেশনটি পারফরম্যান্স উন্নত করে এবং মিসড ফ্রেম কমায়, কিন্তু যেসব ক্লায়েন্ট MessageQueue প্রাইভেট ফিল্ড এবং মেথড রিফ্লেক্ট করে, তাদের ক্ষেত্রে এটি সমস্যা তৈরি করতে পারে।
প্রশমন কৌশল সহ আরও তথ্যের জন্য, MessageQueue-এর আচরণ পরিবর্তন সংক্রান্ত নির্দেশিকা দেখুন।
স্থির চূড়ান্ত ক্ষেত্রগুলি এখন অপরিবর্তনীয়।
অ্যান্ড্রয়েড ১৭ বা তার উচ্চতর সংস্করণে চালিত যে অ্যাপগুলো অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করে, সেগুলো static final ফিল্ড পরিবর্তন করতে পারে না। যদি কোনো অ্যাপ রিফ্লেকশন ব্যবহার করে একটি static final ফিল্ড পরিবর্তন করার চেষ্টা করে, তাহলে এটি একটি IllegalAccessException ঘটাবে। JNI API (যেমন SetStaticLongField() ) এর মাধ্যমে এই ফিল্ডগুলোর কোনো একটি পরিবর্তন করার চেষ্টা করলে অ্যাপটি ক্র্যাশ করবে।
প্রবেশগম্যতা
অ্যান্ড্রয়েড ১৭ অ্যাক্সেসিবিলিটি উন্নত করতে নিম্নলিখিত পরিবর্তনগুলি এনেছে।
জটিল আইএমই ফিজিক্যাল কীবোর্ড টাইপিংয়ের অ্যাক্সেসিবিলিটি সাপোর্ট
এই ফিচারটি CJKV ভাষার ইনপুটের জন্য স্ক্রিন রিডারের মৌখিক ফিডব্যাক উন্নত করতে নতুন AccessibilityEvent এবং TextAttribute API চালু করেছে। CJKV IME অ্যাপগুলো এখন টেক্সট রচনার সময় কোনো টেক্সট রূপান্তর প্রার্থী নির্বাচিত হয়েছে কিনা তা সংকেত দিতে পারে। এডিট ফিল্ডযুক্ত অ্যাপগুলো টেক্সট পরিবর্তনের অ্যাক্সেসিবিলিটি ইভেন্ট পাঠানোর সময় টেক্সট পরিবর্তনের ধরন নির্দিষ্ট করে দিতে পারে। উদাহরণস্বরূপ, অ্যাপগুলো নির্দিষ্ট করতে পারে যে টেক্সট রচনার সময় একটি টেক্সট পরিবর্তন ঘটেছে, অথবা একটি কমিটের ফলে টেক্সট পরিবর্তনটি হয়েছে। এটি করার ফলে স্ক্রিন রিডারের মতো অ্যাক্সেসিবিলিটি পরিষেবাগুলো টেক্সট পরিবর্তনের প্রকৃতির উপর ভিত্তি করে আরও সুনির্দিষ্ট ফিডব্যাক প্রদান করতে সক্ষম হয়।
অ্যাপ গ্রহণ
IME অ্যাপস: এডিট ফিল্ডে কম্পোজিং টেক্সট সেট করার সময়, কোনো নির্দিষ্ট কনভার্সন ক্যান্ডিডেট নির্বাচিত হয়েছে কিনা তা নির্দেশ করতে IME-গুলো
TextAttribute.Builder.setTextSuggestionSelected()ব্যবহার করতে পারে।এডিট ফিল্ডযুক্ত অ্যাপ: যে অ্যাপগুলো একটি কাস্টম
InputConnectionব্যবহার করে, তারাTextAttribute.isTextSuggestionSelected()কল করে সম্ভাব্য নির্বাচনের ডেটা সংগ্রহ করতে পারে। এরপর এই অ্যাপগুলোরTYPE_VIEW_TEXT_CHANGEDইভেন্ট পাঠানোর সময়AccessibilityEvent.setTextChangeTypes()কল করা উচিত। Android 17 (API লেভেল 37) টার্গেট করা যে অ্যাপগুলো স্ট্যান্ডার্ডTextViewব্যবহার করে, সেগুলোতে এই ফিচারটি ডিফল্টভাবে চালু থাকবে। (অর্থাৎ, অ্যাক্সেসিবিলিটি সার্ভিসে ইভেন্ট পাঠানোর সময়TextViewনিজেই IME থেকে ডেটা সংগ্রহ করা এবং টেক্সট পরিবর্তনের ধরন নির্ধারণ করার কাজটি করবে)।অ্যাক্সেসিবিলিটি সার্ভিস: যে অ্যাক্সেসিবিলিটি সার্ভিসগুলো
TYPE_VIEW_TEXT_CHANGEDইভেন্ট প্রসেস করে, তারা পরিবর্তনের প্রকৃতি শনাক্ত করতে এবং সেই অনুযায়ী তাদের ফিডব্যাক কৌশল সামঞ্জস্য করতেAccessibilityEvent.getTextChangeTypes()কল করতে পারে।
গোপনীয়তা
ব্যবহারকারীর গোপনীয়তা উন্নত করার জন্য অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
ECH (এনক্রিপ্টেড ক্লায়েন্ট হ্যালো) সুযোগ বুঝে সক্রিয় করা হয়েছে
অ্যান্ড্রয়েড ১৭-এ এনক্রিপ্টেড ক্লায়েন্ট হ্যালো (ECH)-এর জন্য প্ল্যাটফর্ম সাপোর্ট চালু করা হয়েছে। এটি একটি TLS এক্সটেনশন যা TLS হ্যান্ডশেকের সময় সার্ভার নেম ইন্ডিকেশন (SNI)-কে এনক্রিপ্ট করার মাধ্যমে ব্যবহারকারীর গোপনীয়তা বৃদ্ধি করে। এই এনক্রিপশন নেটওয়ার্ক পর্যবেক্ষকদের পক্ষে আপনার অ্যাপটি কোন নির্দিষ্ট ডোমেইনের সাথে সংযোগ স্থাপন করছে তা সহজে শনাক্ত করা থেকে বিরত রাখতে সাহায্য করে।
অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলির জন্য, টিএলএস সংযোগের ক্ষেত্রে সুযোগ বুঝে ইসিএইচ (ECH) ব্যবহার করা হয়। ইসিএইচ তখনই সক্রিয় থাকে, যখন অ্যাপটিতে ব্যবহৃত নেটওয়ার্কিং লাইব্রেরিতে (যেমন, HttpEngine, WebView, বা OkHttp) ইসিএইচ সাপোর্ট থাকে এবং রিমোট সার্ভারটিও ইসিএইচ প্রোটোকল সমর্থন করে। যদি ইসিএইচ নেগোসিয়েশন সম্ভব না হয়, তবে সংযোগটি স্বয়ংক্রিয়ভাবে এসএনআই (SNI) এনক্রিপশন ছাড়া একটি সাধারণ টিএলএস হ্যান্ডশেকে ফিরে যায়।
অ্যাপগুলোকে এই আচরণটি কাস্টমাইজ করার সুযোগ দিতে, অ্যান্ড্রয়েড ১৭ নেটওয়ার্ক সিকিউরিটি কনফিগারেশন ফাইলে একটি নতুন <domainEncryption> এলিমেন্ট যুক্ত করেছে। ডেভেলপাররা <base-config> বা <domain-config> ট্যাগের মধ্যে <domainEncryption> ব্যবহার করে গ্লোবাল বা ডোমেইন-ভিত্তিক একটি ECH মোড (যেমন, "opportunistic" , "enabled" বা "disabled" ) নির্বাচন করতে পারেন।
আরও তথ্যের জন্য, এনক্রিপ্টেড ক্লায়েন্ট হ্যালো ডকুমেন্টেশন দেখুন।
অ্যান্ড্রয়েড ১৭-এর জন্য তৈরি অ্যাপগুলোর ক্ষেত্রে স্থানীয় নেটওয়ার্কের অনুমতি প্রয়োজন।
অ্যান্ড্রয়েড ১৭ ব্যবহারকারীদের অননুমোদিত লোকাল নেটওয়ার্ক অ্যাক্সেস থেকে রক্ষা করার জন্য ACCESS_LOCAL_NETWORK রানটাইম পারমিশন চালু করেছে। যেহেতু এটি বিদ্যমান NEARBY_DEVICES পারমিশন গ্রুপের অধীনে পড়ে, তাই যেসব ব্যবহারকারী ইতিমধ্যেই অন্যান্য NEARBY_DEVICES পারমিশন দিয়েছেন, তাদের কাছে পুনরায় অনুরোধ করা হয় না। এই নতুন আবশ্যকতাটি ক্ষতিকারক অ্যাপগুলোকে অবাধ লোকাল নেটওয়ার্ক অ্যাক্সেসের সুযোগ নিয়ে গোপনে ব্যবহারকারীকে ট্র্যাক করা এবং ফিঙ্গারপ্রিন্টিং করা থেকে বিরত রাখে। এই পারমিশনটি ঘোষণা এবং অনুরোধ করার মাধ্যমে, আপনার অ্যাপ লোকাল এরিয়া নেটওয়ার্ক (LAN)-এ থাকা ডিভাইস, যেমন স্মার্ট হোম ডিভাইস বা কাস্টিং রিসিভার, খুঁজে বের করতে এবং সেগুলোর সাথে সংযোগ স্থাপন করতে পারে।
অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলোর কাছে এখন ল্যান ডিভাইসগুলোর সাথে যোগাযোগ বজায় রাখার জন্য দুটি পথ রয়েছে: অনুমতির অনুরোধ এড়িয়ে যাওয়ার জন্য সিস্টেম-নিয়ন্ত্রিত ও গোপনীয়তা-সংরক্ষক ডিভাইস পিকার ব্যবহার করা, অথবা স্থানীয় নেটওয়ার্ক যোগাযোগ বজায় রাখার জন্য রানটাইমে স্পষ্টভাবে এই নতুন অনুমতির জন্য অনুরোধ করা।
আরও তথ্যের জন্য, স্থানীয় নেটওয়ার্ক অনুমতি সংক্রান্ত ডকুমেন্টেশন দেখুন।
ভৌত ডিভাইস থেকে পাসওয়ার্ড গোপন করা
If an app targets Android 17 (API level 37) or higher and the user is using
a physical input device (for example, an external keyboard), the Android
operating system applies the new show_passwords_physical setting to all
characters in the password field. By default, that setting hides all password
characters.
The Android system shows the last-typed password character to help the user see if they mistyped the password. However, this is much less necessary with larger external keyboards. In addition, devices with external keyboards often have larger displays, which increases the danger of someone seeing the typed password.
If the user is using the device's touchscreen, the system applies the new
show_passwords_touch setting.
নিরাপত্তা
অ্যান্ড্রয়েড ১৭ ডিভাইস ও অ্যাপ সুরক্ষায় নিম্নলিখিত উন্নতিগুলো এনেছে।
কার্যকলাপ নিরাপত্তা
অ্যান্ড্রয়েড ১৭-তে, প্ল্যাটফর্মটি "নিরাপদ-বাই-ডিফল্ট" আর্কিটেকচারের দিকে তার স্থানান্তর অব্যাহত রেখেছে, ফিশিং, ইন্টারঅ্যাকশন হাইজ্যাকিং এবং বিভ্রান্তিকর ডেপুটি আক্রমণের মতো উচ্চ-তীব্রতা শোষণকে হ্রাস করার জন্য ডিজাইন করা উন্নত বৈশিষ্ট্যগুলির একটি স্যুট প্রবর্তন করছে। এই আপডেটের জন্য ডেভেলপারদের অ্যাপের সামঞ্জস্যতা এবং ব্যবহারকারীর সুরক্ষা বজায় রাখার জন্য স্পষ্টভাবে নতুন সুরক্ষা মানগুলি বেছে নিতে হবে।
ডেভেলপারদের জন্য মূল প্রভাবগুলির মধ্যে রয়েছে:
- BAL শক্তকরণ এবং উন্নত অপ্ট-ইন: আমরা
IntentSenderএ সুরক্ষা সম্প্রসারণ করে ব্যাকগ্রাউন্ড অ্যাক্টিভিটি লঞ্চ (BAL) সীমাবদ্ধতাগুলিকে আরও পরিমার্জন করছি। ডেভেলপারদের অবশ্যই লিগ্যাসিMODE_BACKGROUND_ACTIVITY_START_ALLOWEDধ্রুবক থেকে দূরে সরে যেতে হবে। পরিবর্তে, আপনারMODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLEএর মতো গ্রানুলার নিয়ন্ত্রণ গ্রহণ করা উচিত, যা কার্যকলাপ শুরু করার জন্য এমন পরিস্থিতিতে সীমাবদ্ধ করে যেখানে কলিং অ্যাপটি দৃশ্যমান, আক্রমণের পৃষ্ঠকে উল্লেখযোগ্যভাবে হ্রাস করে। - দত্তক নেওয়ার সরঞ্জাম: ডেভেলপারদের উচিত লিগ্যাসি প্যাটার্ন সনাক্ত করতে এবং ভবিষ্যতের লক্ষ্য SDK প্রয়োজনীয়তার জন্য প্রস্তুতি নিশ্চিত করতে কঠোর মোড এবং আপডেট করা লিন্ট চেক ব্যবহার করা।
ডিফল্টরূপে CT সক্রিয় করুন
If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)
নিরাপদ নেটিভ ডিসিএল—সি
আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করে, তাহলে অ্যান্ড্রয়েড ১৪-এ DEX এবং JAR ফাইলের জন্য চালু হওয়া সেফার ডাইনামিক কোড লোডিং (DCL) সুরক্ষা এখন নেটিভ লাইব্রেরি পর্যন্তও বিস্তৃত হয়েছে।
System.load() ব্যবহার করে লোড করা সমস্ত নেটিভ ফাইলকে অবশ্যই রিড-অনলি হিসেবে চিহ্নিত করতে হবে। অন্যথায়, সিস্টেম UnsatisfiedLinkError থ্রো করে।
আমরা সুপারিশ করি যে অ্যাপগুলো যথাসম্ভব ডায়নামিকভাবে কোড লোড করা থেকে বিরত থাকবে, কারণ এটি করলে কোড ইনজেকশন বা কোড টেম্পারিংয়ের মাধ্যমে অ্যাপটি ক্ষতিগ্রস্ত হওয়ার ঝুঁকি ব্যাপকভাবে বেড়ে যায়।
CP2 ডেটা ভিউতে PII ফিল্ডগুলি সীমাবদ্ধ করুন
অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) এবং এর চেয়ে উচ্চতর সংস্করণের জন্য তৈরি অ্যাপগুলোর ক্ষেত্রে, কন্টাক্টস প্রোভাইডার ২ (CP2) ডেটা ভিউ থেকে ব্যক্তিগতভাবে শনাক্তযোগ্য তথ্য (PII) সম্বলিত নির্দিষ্ট কিছু কলামকে সীমাবদ্ধ করে। যখন এই পরিবর্তনটি সক্রিয় করা হয়, তখন ব্যবহারকারীর গোপনীয়তা বাড়ানোর জন্য এই কলামগুলো ডেটা ভিউ থেকে সরিয়ে দেওয়া হয়। সীমাবদ্ধ কলামগুলোর মধ্যে রয়েছে:
যে অ্যাপগুলি ContactsContract.Data থেকে এই কলামগুলি ব্যবহার করছে, তারা এর পরিবর্তে RAW_CONTACT_ID সাথে জয়েন করে ContactsContract.RawContacts থেকে সেগুলি এক্সট্র্যাক্ট করতে পারে।
CP2-তে কঠোর SQL যাচাই ব্যবস্থা প্রয়োগ করুন।
অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) এবং এর পরবর্তী সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলির ক্ষেত্রে, READ_CONTACTS অনুমতি ছাড়া ContactsContract.Data টেবিলটি অ্যাক্সেস করা হলে Contacts Provider 2 (CP2) কঠোর SQL কোয়েরি যাচাইকরণ প্রয়োগ করে।
এই পরিবর্তনের ফলে, কোনো অ্যাপের READ_CONTACTS পারমিশন না থাকলে, ContactsContract.Data টেবিল কোয়েরি করার সময় StrictColumns এবং StrictGrammar অপশনগুলো সেট হয়ে যাবে। যদি কোনো কোয়েরিতে এমন কোনো প্যাটার্ন ব্যবহার করা হয় যা এগুলোর সাথে সামঞ্জস্যপূর্ণ নয়, তবে সেটি প্রত্যাখ্যাত হবে এবং একটি এক্সেপশন তৈরি করবে।
মিডিয়া
অ্যান্ড্রয়েড ১৭-এ মিডিয়ার আচরণে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
পটভূমির অডিও শক্তিশালীকরণ
Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.
Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:
- The foreground service must have while-in-use (WIU) capabilities.
- The app must have the exact alarm permission and be interacting with
USAGE_ALARMaudio streams.
For more information, including mitigation strategies, see Background audio hardening.
ডিভাইসের ফর্ম ফ্যাক্টর
বিভিন্ন আকারের ও গঠনের ডিভাইসে ব্যবহারকারীর অভিজ্ঞতা উন্নত করার জন্য অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
বড় স্ক্রিনের (sw>=600dp) ক্ষেত্রে ওরিয়েন্টেশন, রিসাইজেবিলিটি এবং অ্যাসপেক্ট রেশিও সংক্রান্ত সীমাবদ্ধতা উপেক্ষা করার জন্য প্ল্যাটফর্ম API-তে পরিবর্তন আনা হয়েছে।
We introduced Platform API changes in Android 16 to ignore orientation, aspect ratio, and resizability restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.
For more information, see Restrictions on orientation and resizability are ignored.
সংযোগ
ব্লুটুথ আরএফসিওএমএম সকেটের ক্ষেত্রে সামঞ্জস্যতা উন্নত করতে এবং স্ট্যান্ডার্ড জাভা InputStream আচরণের সাথে সঙ্গতি রাখতে অ্যান্ড্রয়েড ১৭ নিম্নলিখিত পরিবর্তনটি এনেছে।
RFCOMM-এর জন্য BluetoothSocket read() এর সামঞ্জস্যপূর্ণ আচরণ
অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) টার্গেট করা অ্যাপগুলোর ক্ষেত্রে, RFCOMM-ভিত্তিক BluetoothSocket থেকে প্রাপ্ত InputStream এর read() মেথডটি এখন সকেটটি বন্ধ হয়ে গেলে বা সংযোগ বিচ্ছিন্ন হয়ে গেলে -1 রিটার্ন করে।
এই পরিবর্তনটি RFCOMM সকেটের আচরণকে LE CoC সকেটের সাথে সামঞ্জস্যপূর্ণ করে এবং স্ট্যান্ডার্ড InputStream.read() ডকুমেন্টেশনের সাথে সঙ্গতিপূর্ণ করে, যেখানে বলা হয়েছে যে স্ট্রিমের শেষ প্রান্তে পৌঁছালে -1 রিটার্ন করা হয়।
যেসব অ্যাপ রিড লুপ থেকে বেরিয়ে আসার জন্য শুধুমাত্র IOException ধরার উপর নির্ভর করে, সেগুলো এই পরিবর্তনের দ্বারা প্রভাবিত হতে পারে এবং তাদের BluetoothSocket রিড লুপগুলো আপডেট করে স্পষ্টভাবে -1 রিটার্ন ভ্যালু চেক করা উচিত। এটি নিশ্চিত করে যে রিমোট ডিভাইস সংযোগ বিচ্ছিন্ন হলে বা সকেটটি বন্ধ হয়ে গেলে লুপটি সঠিকভাবে শেষ হয়। প্রস্তাবিত বাস্তবায়নের একটি উদাহরণের জন্য, "ট্রান্সফার ব্লুটুথ ডেটা" গাইডের কোড স্নিপেটটি দেখুন।