আচরণগত পরিবর্তন: অ্যান্ড্রয়েড ১৭ বা তার উচ্চতর ভার্সনকে লক্ষ্য করে অ্যাপ

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

আপনার অ্যাপের 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)-কে এনক্রিপ্ট করার মাধ্যমে ব্যবহারকারীর গোপনীয়তা বৃদ্ধি করে। এই এনক্রিপশন নেটওয়ার্ক পর্যবেক্ষকদের পক্ষে আপনার অ্যাপটি কোন নির্দিষ্ট ডোমেইনের সাথে সংযোগ স্থাপন করছে তা সহজে শনাক্ত করা থেকে বিরত রাখতে সাহায্য করে।

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" ) নির্বাচন করতে পারেন।

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

অ্যান্ড্রয়েড ১৭-এর জন্য তৈরি অ্যাপগুলোর ক্ষেত্রে স্থানীয় নেটওয়ার্কের অনুমতি প্রয়োজন।

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

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

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

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

ভৌত ডিভাইস থেকে পাসওয়ার্ড গোপন করা

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

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

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

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

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

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

দ্রষ্টব্য: WebOTP এবং SMS Retriever ফরম্যাটের মেসেজের জন্য অতিরিক্ত SMS OTP সুরক্ষা, তাদের টার্গেট API লেভেল নির্বিশেষে সকল অ্যাপের জন্য প্রযোজ্য। আরও তথ্যের জন্য, সকল অ্যাপের আচরণগত পরিবর্তন সংক্রান্ত ডকুমেন্টেশনে SMS OTP সুরক্ষা দেখুন।

নিরাপত্তা

অ্যান্ড্রয়েড ১৭ ডিভাইস ও অ্যাপ সুরক্ষায় নিম্নলিখিত উন্নতিগুলো এনেছে।

কার্যকলাপ নিরাপত্তা

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

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

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

ডিফল্টরূপে CT সক্রিয় করুন

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

নিরাপদ নেটিভ ডিসিএল—সি

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

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

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

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

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

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

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

CP2-তে কঠোর SQL যাচাই ব্যবস্থা প্রয়োগ করুন।

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

এই পরিবর্তনের ফলে, কোনো অ্যাপের READ_CONTACTS পারমিশন না থাকলে, ContactsContract.Data টেবিল কোয়েরি করার সময় StrictColumns এবং StrictGrammar অপশনগুলো সেট হয়ে যাবে। যদি কোনো কোয়েরিতে এমন কোনো প্যাটার্ন ব্যবহার করা হয় যা এগুলোর সাথে সামঞ্জস্যপূর্ণ নয়, তবে সেটি প্রত্যাখ্যাত হবে এবং একটি এক্সেপশন তৈরি করবে।

মিডিয়া

অ্যান্ড্রয়েড ১৭-এ মিডিয়ার আচরণে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

পটভূমির অডিও শক্তিশালীকরণ

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

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

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

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

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

বিভিন্ন আকারের ও গঠনের ডিভাইসে ব্যবহারকারীর অভিজ্ঞতা উন্নত করার জন্য অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

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

আমরা অ্যান্ড্রয়েড ১৬-এ প্ল্যাটফর্ম এপিআই-তে কিছু পরিবর্তন এনেছি, যার ফলে এপিআই লেভেল ৩৬ বা তার বেশি টার্গেট করা অ্যাপগুলো বড় স্ক্রিনে (sw >= 600dp) ওরিয়েন্টেশন, অ্যাসপেক্ট রেশিও এবং রিসাইজেবিলিটির সীমাবদ্ধতা উপেক্ষা করতে পারবে । ডেভেলপারদের কাছে এসডিকে ৩৬ ব্যবহার করে এই পরিবর্তনগুলো থেকে বেরিয়ে আসার সুযোগ রয়েছে, কিন্তু অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার বেশি টার্গেট করা অ্যাপগুলোর জন্য এই সুবিধাটি আর থাকবে না।

আরও তথ্যের জন্য, দেখুন অভিমুখ এবং আকার পরিবর্তনের উপর বিধিনিষেধ উপেক্ষা করা হয় ।

সংযোগ

ব্লুটুথ আরএফসিওএমএম সকেটের ক্ষেত্রে সামঞ্জস্যতা উন্নত করতে এবং স্ট্যান্ডার্ড জাভা InputStream আচরণের সাথে সঙ্গতি রাখতে অ্যান্ড্রয়েড ১৭ নিম্নলিখিত পরিবর্তনটি এনেছে।

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

对于以 Android 17（API 级别 37）为目标平台的应用， read() 方法从InputStream 获取的 基于 RFCOMM 的 BluetoothSocket 现在会在 套接字关闭或连接断开时返回 -1。

此更改使 RFCOMM 套接字行为与 LE CoC 套接字保持一致，并与标准 InputStream.read() 文档保持一致，该文档指出，当到达流的末尾时，系统会返回 -1。

仅依赖于捕获 IOException 以跳出读取循环的应用可能会受到此更改的影响，并且应更新 BluetoothSocket 读取循环以明确检查返回值 -1。这可确保在远程设备断开连接或套接字关闭时，循环正确终止。如需查看推荐的实现示例，请参阅传输蓝牙数据指南中的代码段。