আচরণগত পরিবর্তন: Android 17 বা এর পরের যেকোনও ভার্সনকে টার্গেট করা অ্যাপ

আগের রিলিজের মতো, Android 17-এ এমন আচরণগত পরিবর্তন অন্তর্ভুক্ত রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণগত পরিবর্তনগুলি শুধুমাত্র সেইসব অ্যাপের ক্ষেত্রে প্রযোজ্য যেগুলি Android 17 বা তার পরের যেকোনও ভার্সনকে টার্গেট করছে। আপনার অ্যাপ Android 17 বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করলে, যেখানে প্রযোজ্য সেখানে এইসব আচরণ সমর্থন করার জন্য আপনার অ্যাপকে পরিবর্তন করতে হবে।

Android 17-এ চলে এমন সব অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তন-এর তালিকাও পর্যালোচনা করতে ভুলবেন না, আপনার অ্যাপের targetSdkVersion যাই হোক না কেন।

ব্যবহারকারীর অভিজ্ঞতা ও সিস্টেম UI

Android 17-এ নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করা হয়েছে, যেগুলি আরও সঙ্গত, স্বজ্ঞাত ব্যবহারকারীর অভিজ্ঞতা তৈরি করার উদ্দেশ্যে করা হয়েছে।

মেমরি সীমা উইজেট

Android 17 থেকে শুরু করে, Android 17 (API লেভেল 37) বা তার পরের ভার্সনকে টার্গেট করা অ্যাপের জন্য, সিস্টেম কঠোরভাবে মেমরি সীমা (1.5 * স্ক্রিনের প্রস্থ * স্ক্রিনের দৈর্ঘ্য * 4) প্রয়োগ করে। এটি RemoteViews পার্সেলের মধ্যে থাকা বিটম্যাপ ও আইকনের সম্মিলিত মেমরি ব্যবহারের উপর প্রয়োগ করা হয়। এইসব সীমা অতিক্রম করলে, একটি মারাত্মক IllegalArgumentException হয় এবং অ্যাপের প্রসেস ক্র্যাশ করে।

আরও তথ্যের জন্য, UpdateAppWidget দেখুন।

মূল কার্যকারিতা

Android 17-এ নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে যা Android সিস্টেমের বিভিন্ন মূল ক্ষমতাকে পরিবর্তন বা সম্প্রসারিত করে।

MessageQueue-এর নতুন লক-ফ্রি প্রয়োগ

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করা অ্যাপগুলো android.os.MessageQueue এর একটি নতুন লক-ফ্রি ইমপ্লিমেন্টেশন পাবে। এই নতুন ইমপ্লিমেন্টেশনটি পারফরম্যান্স উন্নত করে এবং মিসড ফ্রেম কমায়, কিন্তু যেসব ক্লায়েন্ট MessageQueue প্রাইভেট ফিল্ড এবং মেথড রিফ্লেক্ট করে, তাদের ক্ষেত্রে এটি সমস্যা তৈরি করতে পারে।

প্রশমন কৌশল সহ আরও তথ্যের জন্য, MessageQueue-এর আচরণ পরিবর্তন সংক্রান্ত নির্দেশিকা দেখুন।

স্ট্যাটিক ফাইনাল ফিল্ড এখন আর পরিবর্তন করা যায় না

অ্যান্ড্রয়েড ১৭ বা তার উচ্চতর সংস্করণে চালিত যে অ্যাপগুলো অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করে, সেগুলো static final ফিল্ড পরিবর্তন করতে পারে না। যদি কোনো অ্যাপ রিফ্লেকশন ব্যবহার করে একটি static final ফিল্ড পরিবর্তন করার চেষ্টা করে, তাহলে এটি একটি IllegalAccessException ঘটাবে। JNI API (যেমন SetStaticLongField() ) এর মাধ্যমে এই ফিল্ডগুলোর কোনো একটি পরিবর্তন করার চেষ্টা করলে অ্যাপটি ক্র্যাশ করবে।

অ্যাক্সেসিবিলিটি

অ্যাক্সেসিবিলিটি উন্নত করতে Android 17 নিম্নলিখিত পরিবর্তনগুলি করে।

জটিল IME ফিজিক্যাল কীবোর্ড টাইপিংয়ের অ্যাক্সেসিবিলিটি সহায়তা

এই ফিচারটি 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() কল করতে পারে।

গোপনীয়তা

ব্যবহারকারীর গোপনীয়তা উন্নত করতে Android 17-এ নিম্নলিখিত পরিবর্তন করা হয়েছে।

ECH (এনক্রিপটেড ক্লায়েন্ট হ্যালো) চালু করা আছে

অ্যান্ড্রয়েড ১৭-এ এনক্রিপ্টেড ক্লায়েন্ট হ্যালো (ECH)-এর জন্য প্ল্যাটফর্ম সাপোর্ট চালু করা হয়েছে। এটি একটি TLS এক্সটেনশন যা TLS হ্যান্ডশেকের সময় সার্ভার নেম ইন্ডিকেশন (SNI)-কে এনক্রিপ্ট করার মাধ্যমে ব্যবহারকারীর গোপনীয়তা বৃদ্ধি করে। এই এনক্রিপশন নেটওয়ার্ক পর্যবেক্ষকদের পক্ষে আপনার অ্যাপটি কোন নির্দিষ্ট ডোমেইনের সাথে সংযোগ স্থাপন করছে তা সহজে শনাক্ত করা থেকে বিরত রাখতে সাহায্য করে।

Android 17 (API লেভেল 37) বা তার উচ্চতর সংস্করণের অ্যাপগুলির জন্য TLS কানেকশনে ECH ব্যবহৃত হয়। ECH তখনই সক্রিয় থাকে যখন অ্যাপটিতে ব্যবহৃত নেটওয়ার্কিং লাইব্রেরিতে (যেমন, HttpEngine, WebView, বা OkHttp) ইন্টিগ্রেটেড ECH সাপোর্ট থাকে এবং রিমোট সার্ভারটিও ECH প্রোটোকল সাপোর্ট করে। যদি ECH নেগোসিয়েট করা না যায়, তবে ক্লায়েন্ট র‍্যান্ডমাইজড কন্টেন্টসহ একটি ECH এক্সটেনশন পাঠায় (এই পদ্ধতিকে ECH GREASE বলা হয়)। ECH GREASE কীভাবে কাজ করে সে সম্পর্কে আরও বিস্তারিত জানতে RFC 9849 দেখুন।

অ্যাপগুলোকে এই আচরণটি কাস্টমাইজ করার সুযোগ দিতে, অ্যান্ড্রয়েড ১৭ নেটওয়ার্ক সিকিউরিটি কনফিগারেশন ফাইলে একটি নতুন <domainEncryption> এলিমেন্ট যুক্ত করেছে। ডেভেলপাররা <base-config> বা <domain-config> ট্যাগের মধ্যে <domainEncryption> ব্যবহার করে গ্লোবাল বা ডোমেইন-ভিত্তিক একটি ECH মোড (যেমন, "enabled" বা "disabled" ) নির্বাচন করতে পারেন।

আরও তথ্যের জন্য, এনক্রিপ্টেড ক্লায়েন্ট হ্যালো ডকুমেন্টেশন দেখুন।

Android 17 টার্গেট করা অ্যাপের জন্য লোকাল নেটওয়ার্ক সংক্রান্ত অনুমতি প্রয়োজন

অ্যান্ড্রয়েড ১৭ ব্যবহারকারীদের অননুমোদিত লোকাল নেটওয়ার্ক অ্যাক্সেস থেকে রক্ষা করার জন্য ACCESS_LOCAL_NETWORK রানটাইম পারমিশন চালু করেছে। যেহেতু এটি বিদ্যমান NEARBY_DEVICES পারমিশন গ্রুপের অধীনে পড়ে, তাই যেসব ব্যবহারকারী ইতিমধ্যেই অন্যান্য NEARBY_DEVICES পারমিশন দিয়েছেন, তাদের কাছে পুনরায় অনুরোধ করা হয় না। এই নতুন আবশ্যকতাটি ক্ষতিকারক অ্যাপগুলোকে অবাধ লোকাল নেটওয়ার্ক অ্যাক্সেসের সুযোগ নিয়ে গোপনে ব্যবহারকারীকে ট্র্যাক করা এবং ফিঙ্গারপ্রিন্টিং করা থেকে বিরত রাখে। এই পারমিশনটি ঘোষণা এবং অনুরোধ করার মাধ্যমে, আপনার অ্যাপ লোকাল এরিয়া নেটওয়ার্ক (LAN)-এ থাকা ডিভাইস, যেমন স্মার্ট হোম ডিভাইস বা কাস্টিং রিসিভার, খুঁজে বের করতে এবং সেগুলোর সাথে সংযোগ স্থাপন করতে পারে।

অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলোর কাছে এখন ল্যান ডিভাইসগুলোর সাথে যোগাযোগ বজায় রাখার জন্য দুটি পথ রয়েছে: অনুমতির অনুরোধ এড়িয়ে যাওয়ার জন্য সিস্টেম-নিয়ন্ত্রিত ও গোপনীয়তা-সংরক্ষক ডিভাইস পিকার ব্যবহার করা, অথবা স্থানীয় নেটওয়ার্ক যোগাযোগ বজায় রাখার জন্য রানটাইমে স্পষ্টভাবে এই নতুন অনুমতির জন্য অনুরোধ করা।

আরও তথ্যের জন্য, স্থানীয় নেটওয়ার্ক অনুমতি সংক্রান্ত ডকুমেন্টেশন দেখুন।

ফিজিক্যাল ডিভাইস থেকে পাসওয়ার্ড লুকানো

যদি কোনো অ্যাপ অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করে এবং ব্যবহারকারী কোনো ফিজিক্যাল ইনপুট ডিভাইস (যেমন, একটি এক্সটার্নাল কিবোর্ড) ব্যবহার করেন, তাহলে অ্যান্ড্রয়েড অপারেটিং সিস্টেম পাসওয়ার্ড ফিল্ডের সমস্ত অক্ষরের উপর নতুন show_passwords_physical সেটিংটি প্রয়োগ করে। ডিফল্টরূপে, এই সেটিংটি পাসওয়ার্ডের সমস্ত অক্ষর লুকিয়ে রাখে।

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

ব্যবহারকারী যদি ডিভাইসটির টাচস্ক্রিন ব্যবহার করেন, তাহলে সিস্টেমটি নতুন show_passwords_touch সেটিংটি প্রয়োগ করে।

সাধারণ এসএমএস মেসেজের জন্য ওটিপি সুরক্ষা

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অ্যান্ড্রয়েড তার এসএমএস ওটিপি সুরক্ষা সাধারণ এসএমএস বার্তাগুলিতেও (যেসব এসএমএস বার্তায় ওটিপি থাকে কিন্তু WebOTP বা SMS Retriever ফরম্যাট ব্যবহার করে না) প্রয়োগ করছে। অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি বেশিরভাগ অ্যাপের জন্য, এই এসএমএস বার্তাগুলি পাওয়ার তিন ঘণ্টা পর পর্যন্ত উপলব্ধ হয় না। এই বিলম্বের উদ্দেশ্য হলো ওটিপি হাইজ্যাকিং প্রতিরোধে সহায়তা করা। এই তিন ঘণ্টার বিলম্বকালে, SMS_RECEIVED_ACTION ব্রডকাস্টটি স্থগিত রাখা হয় এবং এসএমএস প্রদানকারীর ডাটাবেস কোয়েরিগুলি ফিল্টার করা হয়। এই বিলম্বের পর এসএমএস বার্তাটি অ্যাপগুলির জন্য উপলব্ধ হয়।

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

নিরাপত্তা

Android 17 ডিভাইস ও অ্যাপের নিরাপত্তায় নিম্নলিখিত উন্নতি করে।

অ্যাক্টিভিটি সংক্রান্ত নিরাপত্তা

অ্যান্ড্রয়েড ১৭-এ, প্ল্যাটফর্মটি "ডিফল্টরূপে সুরক্ষিত" আর্কিটেকচারের দিকে তার পরিবর্তন অব্যাহত রেখেছে এবং ফিশিং, ইন্টার‍্যাকশন হাইজ্যাকিং, ও কনফিউজড ডেপুটি অ্যাটাকের মতো গুরুতর এক্সপ্লয়েটগুলো প্রশমিত করার জন্য একগুচ্ছ উন্নত বৈশিষ্ট্য নিয়ে এসেছে। এই আপডেটের ফলে অ্যাপের সামঞ্জস্যতা এবং ব্যবহারকারীর সুরক্ষা বজায় রাখার জন্য ডেভেলপারদের নতুন নিরাপত্তা মানগুলোতে স্পষ্টভাবে সম্মতি জানাতে হবে।

ডেভেলপারদের জন্য প্রধান প্রভাবগুলো হলো:

• BAL সুরক্ষা বৃদ্ধি এবং উন্নত অপ্ট-ইন: আমরা IntentSender পর্যন্ত সুরক্ষা প্রসারিত করে ব্যাকগ্রাউন্ড অ্যাক্টিভিটি লঞ্চ (BAL) বিধিনিষেধ পরিমার্জন করছি। ডেভেলপারদের অবশ্যই পুরোনো MODE_BACKGROUND_ACTIVITY_START_ALLOWED কনস্ট্যান্টটি ব্যবহার করা থেকে সরে আসতে হবে। এর পরিবর্তে, আপনাদের MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE এর মতো সূক্ষ্ম নিয়ন্ত্রণ ব্যবস্থা গ্রহণ করা উচিত, যা অ্যাক্টিভিটি শুরু হওয়াকে শুধুমাত্র সেইসব পরিস্থিতিতে সীমাবদ্ধ করে যেখানে কলিং অ্যাপটি দৃশ্যমান থাকে, ফলে আক্রমণের ঝুঁকি উল্লেখযোগ্যভাবে হ্রাস পায়।
• অভিযোজন সরঞ্জাম: ডেভেলপারদের উচিত লিগ্যাসি প্যাটার্ন শনাক্ত করতে এবং ভবিষ্যতের টার্গেট SDK-এর প্রয়োজনীয়তার জন্য প্রস্তুতি নিশ্চিত করতে স্ট্রিক্ট মোড এবং আপডেটেড লিন্ট চেক ব্যবহার করা।

ডিফল্ট হিসেবে CT চালু করা

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

Safer Native DCL—C

আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করে, তাহলে অ্যান্ড্রয়েড ১৪-এ DEX এবং JAR ফাইলের জন্য চালু হওয়া সেফার ডাইনামিক কোড লোডিং (DCL) সুরক্ষা এখন নেটিভ লাইব্রেরি পর্যন্তও বিস্তৃত হয়েছে।

System.load() ব্যবহার করে লোড করা সমস্ত নেটিভ ফাইলকে অবশ্যই রিড-অনলি হিসেবে চিহ্নিত করতে হবে। অন্যথায়, সিস্টেম UnsatisfiedLinkError থ্রো করে।

আমরা সুপারিশ করি যে অ্যাপগুলো যথাসম্ভব ডায়নামিকভাবে কোড লোড করা থেকে বিরত থাকবে, কারণ এমনটা করলে কোড ইনজেকশন বা কোড টেম্পারিংয়ের মাধ্যমে অ্যাপটি ক্ষতিগ্রস্ত হওয়ার ঝুঁকি ব্যাপকভাবে বেড়ে যায়।

CP2 ডেটা ভিউতে PII ফিল্ড সীমাবদ্ধ করা

Android 17 (API লেভেল 37) ও এর পরের ভার্সন টার্গেট করা অ্যাপের ক্ষেত্রে, পরিচিতি প্রদানকারী ২ (CP2) ডেটা ভিউ থেকে ব্যক্তিগতভাবে শনাক্তকরণযোগ্য তথ্য (PII) থাকা নির্দিষ্ট কলাম সীমাবদ্ধ করে। এই পরিবর্তন চালু করা হলে, ব্যবহারকারীর গোপনীয়তা আরও সুরক্ষিত করতে ডেটা ভিউ থেকে এইসব কলাম সরিয়ে দেওয়া হয়। বিধিনিষেধযুক্ত কলামের মধ্যে এগুলি অন্তর্ভুক্ত:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

ContactsContract.Data থেকে এইসব কলাম ব্যবহার করা অ্যাপগুলি RAW_CONTACT_ID-এর সাথে যোগ করে, পরিবর্তে ContactsContract.RawContacts থেকে এগুলি এক্সট্র্যাক্ট করতে পারে।

CP2-তে কঠোর SQL চেক প্রয়োগ করা

Android 17 (API লেভেল 37) ও এর পরের যেকোনও ভার্সনের জন্য তৈরি অ্যাপের ক্ষেত্রে, Contacts Provider 2 (CP2) কঠোরভাবে SQL কোয়েরি যাচাই করে যখন READ_CONTACTS অনুমতি ছাড়া ContactsContract.Data টেবিল অ্যাক্সেস করা হয়।

এই পরিবর্তনের ফলে, কোনও অ্যাপের কাছে READ_CONTACTS অনুমতি না থাকলে, StrictColumns এবং StrictGrammar বিকল্পগুলি ContactsContract.Data টেবিল কোয়েরি করার সময় সেট করা হয়। কোনও কোয়েরি এমন প্যাটার্ন ব্যবহার করলে যা এগুলির সাথে মানানসই নয়, সেটি বাতিল করা হবে এবং ব্যতিক্রম তৈরি হবে।

ইনটেলিজেন্স

Android 17-এ সিস্টেম ইন্টেলিজেন্সে নিম্নলিখিত পরিবর্তন করা হয়েছে।

setContentCaptureEnabled বন্ধ করা

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

অ্যান্ড্রয়েড ১৭ থেকে, ContentCaptureManager.setContentCaptureEnabled(boolean) API মেথডটি অপ্রচলিত (deprecated) করা হয়েছে। যেসব অ্যাপ অ্যান্ড্রয়েড ১৭ (API লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করে, setContentCaptureEnabled(false) কল করলে এখন আর কন্টেন্ট ক্যাপচার নিষ্ক্রিয় হয় না।

আপনার অ্যাপ যদি কন্টেন্ট ক্যাপচার নিষ্ক্রিয় রাখা অব্যাহত রাখতে চায় অথবা সিস্টেম দ্বারা স্ক্রিনের বিষয়বস্তু ক্যাপচার হওয়া সীমাবদ্ধ করতে চায়, তাহলে আপনাকে অবশ্যই FLAG_SECURE উইন্ডো লেআউট প্যারামিটার ব্যবহার শুরু করতে হবে।

কন্টেন্ট ক্যাপচার নিষ্ক্রিয় করতে, নিম্নলিখিত উদাহরণে দেখানো অনুযায়ী আপনার উইন্ডোতে FLAG_SECURE ফ্ল্যাগটি সেট করুন:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

আরও বিস্তারিত তথ্যের জন্য, WindowManager.LayoutParams.FLAG_SECURE রেফারেন্স ডকুমেন্টেশন দেখুন।

মিডিয়া

Android 17-এ মিডিয়া আচরণে নিম্নলিখিত পরিবর্তন করা হয়েছে।

ব্যাকগ্রাউন্ড অডিও হার্ডেনিং

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অডিও ফ্রেমওয়ার্ক ব্যাকগ্রাউন্ডে অডিও ইন্টারঅ্যাকশনের উপর বিধিনিষেধ আরোপ করে। এর মধ্যে রয়েছে অডিও প্লেব্যাক, অডিও ফোকাস রিকোয়েস্ট এবং ভলিউম পরিবর্তনের এপিআই। এর উদ্দেশ্য হলো, এই পরিবর্তনগুলো যেন ব্যবহারকারীর ইচ্ছাকৃত উদ্যোগেই শুরু হয় তা নিশ্চিত করা।

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

• ফোরগ্রাউন্ড সার্ভিসটিতে অবশ্যই ব্যবহারের সময় সক্রিয় থাকার (WIU) সক্ষমতা থাকতে হবে।
• অ্যাপটির অবশ্যই সঠিক অ্যালার্ম পারমিশন থাকতে হবে এবং USAGE_ALARM অডিও স্ট্রিমগুলোর সাথে ইন্টারঅ্যাক্ট করতে হবে।

প্রশমন কৌশল সহ আরও তথ্যের জন্য, ব্যাকগ্রাউন্ড অডিও হার্ডেনিং দেখুন।

ডিভাইস ফর্ম ফ্যাক্টর

বিভিন্ন সাইজ ও ফর্ম ফ্যাক্টর জুড়ে ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে Android 17-এ নিম্নলিখিত পরিবর্তন করা হয়েছে।

বড় স্ক্রিনে (sw>=600dp) ওরিয়েন্টেশন, রিসাইজেবিলিটি ও অ্যাস্পেক্ট রেশিও সংক্রান্ত বিধিনিষেধ উপেক্ষা করার জন্য প্ল্যাটফর্ম API-তে পরিবর্তন

API লেভেল ৩৬ বা তার পরের যেকোনও লেভেল টার্গেট করা অ্যাপের জন্য অরিয়েন্টেশন, রি-সাইজেবিলিটি এবং বড় স্ক্রিনে (sw >= 600dp) অ্যাস্পেক্ট রেশিও সংক্রান্ত বিধিনিষেধ উপেক্ষা করতে আমরা Android 16-এ প্ল্যাটফর্ম API পরিবর্তন করেছি। SDK 36-এর মাধ্যমে ডেভেলপাররা এইসব পরিবর্তন থেকে বেরিয়ে আসতে পারবেন, তবে Android 17 (API লেভেল 37) বা এর পরের যেকোনও ভার্সনকে টার্গেট করা অ্যাপের জন্য এই বেরিয়ে আসার সুবিধা আর উপলভ্য থাকবে না।

আরও তথ্যের জন্য, অরিয়েন্টেশন ও রিসাইজ করার উপর বিধিনিষেধ উপেক্ষা করা হয় দেখুন।

কানেক্টিভিটি

Android 17, ব্লুটুথ RFCOMM সকেটের জন্য ধারাবাহিকতা উন্নত করতে এবং স্ট্যান্ডার্ড Java InputStream আচরণের সাথে অ্যালাইন করতে নিম্নলিখিত পরিবর্তন নিয়ে এসেছে।

RFCOMM-এর জন্য সামঞ্জস্যপূর্ণ BluetoothSocket read() আচরণ

অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) টার্গেট করা অ্যাপগুলোর ক্ষেত্রে, RFCOMM-ভিত্তিক BluetoothSocket থেকে প্রাপ্ত InputStream এর read() মেথডটি এখন সকেটটি বন্ধ হয়ে গেলে বা সংযোগ বিচ্ছিন্ন হয়ে গেলে -1 রিটার্ন করে।

এই পরিবর্তনটি RFCOMM সকেটের আচরণকে LE CoC সকেটের সাথে সামঞ্জস্যপূর্ণ করে এবং স্ট্যান্ডার্ড InputStream.read() ডকুমেন্টেশনের সাথে সঙ্গতিপূর্ণ করে, যেখানে বলা হয়েছে যে স্ট্রিমের শেষ প্রান্তে পৌঁছালে -1 রিটার্ন করা হয়।

যেসব অ্যাপ রিড লুপ থেকে বেরিয়ে আসার জন্য শুধুমাত্র IOException ধরার উপর নির্ভর করে, সেগুলো এই পরিবর্তনের দ্বারা প্রভাবিত হতে পারে এবং তাদের BluetoothSocket রিড লুপগুলো আপডেট করে স্পষ্টভাবে -1 রিটার্ন ভ্যালু চেক করা উচিত। এটি নিশ্চিত করে যে রিমোট ডিভাইস সংযোগ বিচ্ছিন্ন হলে বা সকেটটি বন্ধ হয়ে গেলে লুপটি সঠিকভাবে শেষ হয়। প্রস্তাবিত বাস্তবায়নের একটি উদাহরণের জন্য, "ট্রান্সফার ব্লুটুথ ডেটা" গাইডের কোড স্নিপেটটি দেখুন।