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

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

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

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

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

মেমরির সীমা সংক্রান্ত উইজেট

Android 17 থেকে শুরু করে, Android 17 (API লেভেল ৩৭) বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপের জন্য, সিস্টেম RemoteViews পার্সেলে থাকা বিটম্যাপ ও আইকন, উভয়ের সম্মিলিত মেমরি ব্যবহারের উপর একটি কঠোর মেমরি সীমা (১.৫ * স্ক্রিনের প্রস্থ * স্ক্রিনের উচ্চতা * ৪) এনফোর্স করে। এই সীমাবদ্ধতা না মানলে মারাত্মক IllegalArgumentException হয় এবং অ্যাপের প্রসেস ক্র্যাশ করে।

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

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

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

MessageQueue-এর নতুন লক-ফ্রি ইমপ্লিমেন্টেশন

Android 17 থেকে শুরু করে, Android 17 (API লেভেল 37) বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপগুলি android.os.MessageQueue-এর একটি নতুন লক-ফ্রি ইমপ্লিমেন্টেশন পায়। নতুন ইমপ্লিমেন্টেশন পারফর্ম্যান্স উন্নত করে এবং মিস হওয়া ফ্রেমের সংখ্যা কমায়, তবে MessageQueue-এ প্রতিফলিত হওয়া ক্লায়েন্টদের ব্যক্তিগত ফিল্ড ও পদ্ধতি ভেঙে দিতে পারে।

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

Static final ফিল্ড এখন আর পরিবর্তন করা যাবে না

Android 17 বা তার পরবর্তী ভার্সনে রান করা অ্যাপ যা Android 17 (API লেভেল 37) বা তার পরবর্তী ভার্সনকে টার্গেট করে, সেগুলি 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 ১৭ (API লেভেল ৩৭) টার্গেট করা যেসব অ্যাপ স্ট্যান্ডার্ড TextView ব্যবহার করে, সেগুলিতে এই ফিচার ডিফল্ট হিসেবে চালু থাকবে। (অর্থাৎ, TextView IME থেকে ডেটা ফিরিয়ে আনা এবং অ্যাক্সেসিবিলিটি পরিষেবায় ইভেন্ট পাঠানোর সময় টেক্সট পরিবর্তনের ধরন সেট করার বিষয়টি ম্যানেজ করবে)।

  • অ্যাক্সেসিবিলিটি পরিষেবা: অ্যাক্সেসিবিলিটি পরিষেবা যা TYPE_VIEW_TEXT_CHANGED ইভেন্ট প্রসেস করে, তা AccessibilityEvent.getTextChangeTypes() কল করতে পারে যাতে পরিবর্তনের ধরন শনাক্ত করা যায় এবং সেই অনুযায়ী তাদের ফিডব্যাক স্ট্র্যাটেজি অ্যাডজাস্ট করা যায়।

গোপনীয়তা

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

ECH (এনক্রিপটেড Client Hello) চালু করা আছে

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

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

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

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

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

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

Android 17 (API লেভেল 37) বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপের কাছে এখন LAN ডিভাইসের সাথে কমিউনিকেশন বজায় রাখার জন্য দুটি পথ রয়েছে: সিস্টেম-মধ্যস্থতাকারী, গোপনীয়তা-সংরক্ষণকারী ডিভাইস পিকার গ্রহণ করে অনুমতির প্রম্পট এড়িয়ে যাওয়া অথবা লোকাল নেটওয়ার্ক কমিউনিকেশন বজায় রাখার জন্য রানটাইমে স্পষ্টভাবে এই নতুন অনুমতির জন্য অনুরোধ করা।

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

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

কোনও অ্যাপ Android 17 (API লেভেল 37) বা তার পরবর্তী ভার্সনকে টার্গেট করলে এবং ব্যবহারকারী ফিজিক্যাল ইনপুট ডিভাইস (যেমন, এক্সটার্নাল কীবোর্ড) ব্যবহার করলে, Android অপারেটিং সিস্টেম পাসওয়ার্ড ফিল্ডের সব অক্ষরের ক্ষেত্রে নতুন show_passwords_physical সেটিং প্রয়োগ করে। ডিফল্ট হিসেবে, সেই সেটিং পাসওয়ার্ডের সব অক্ষর লুকিয়ে রাখে।

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

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

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

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

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

নিরাপত্তা

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

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

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

ডেভেলপারদের জন্য প্রধান প্রভাবের মধ্যে এগুলি পড়ে:

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

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

কোনও অ্যাপ Android 17 (API লেভেল 37) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করলে, সার্টিফিকেট ট্রান্সপারেন্সি (CT) ডিফল্ট হিসেবে চালু হয়ে যায়। (Android 16-এ, CT উপলভ্য কিন্তু অ্যাপকে চালু করতে হবে।)

Safer Native DCL—C

আপনার অ্যাপ Android 17 (API লেভেল 37) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করলে, DEX ও JAR ফাইলের জন্য Android 14-এ চালু করা Safer Dynamic Code Loading (DCL) সুরক্ষা এখন নেটিভ লাইব্রেরিতেও কাজ করবে।

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

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

CP2 ডেটা ভিউতে PII ফিল্ডে বিধিনিষেধ আরোপ করা

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

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

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

Android ১৭ (API লেভেল ৩৭) এবং তার চেয়ে উন্নত ভার্সন টার্গেট করা অ্যাপের ক্ষেত্রে, READ_CONTACTS অনুমতি ছাড়া ContactsContract.Data টেবিল অ্যাক্সেস করা হলে, Contacts Provider 2 (CP2) কঠোর SQL কোয়েরি যাচাইকরণ এনফোর্স করে।

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

ইন্টেলিজেন্স

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

setContentCaptureEnabled বন্ধ করা

কিছু ডিভাইসে ডিফল্ট হিসেবে কন্টেন্ট ক্যাপচার চালু করা থাকে যাতে অন-ডিভাইস AI ফিচার ইন্টেলিজেন্ট অভিজ্ঞতার জন্য স্ক্রিন কন্টেন্ট বিশ্লেষণ করতে পারে।

Android ১৭ থেকে, ContentCaptureManager.setContentCaptureEnabled(boolean) API পদ্ধতি অবচিত করা হয়েছে। Android 17 (API লেভেল ৩৭) বা তার পরবর্তী ভার্সনকে টার্গেট করে এমন অ্যাপের ক্ষেত্রে, setContentCaptureEnabled(false) কল করলে কন্টেন্ট ক্যাপচার আর বন্ধ হয় না।

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

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

Kotlin

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-এ মিডিয়া ব্যবহারের ক্ষেত্রে নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করা হয়েছে।

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

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

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

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

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

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

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

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

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

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

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

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

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

Android 17 (API লেভেল 37) টার্গেট করা অ্যাপের জন্য, RFCOMM-ভিত্তিক BluetoothSocket থেকে পাওয়া InputStream-এর read() পদ্ধতি এখন সকেট বন্ধ হয়ে গেলে বা কানেকশন ড্রপ হয়ে গেলে -1 রিটার্ন করে।

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

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