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

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

অ্যান্ড্রয়েড ১৭-কে লক্ষ্য করে তৈরি অ্যাপগুলোর জন্য প্রযোজ্য আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।

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

অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭)-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত রয়েছে, যা অ্যান্ড্রয়েড সিস্টেমের বিভিন্ন মূল সক্ষমতাকে সংশোধন বা প্রসারিত করে।

অ্যাপের মেমরি সীমা

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

ApplicationExitInfo তে getDescription কল করে আপনি জানতে পারবেন আপনার অ্যাপ সেশনটি প্রভাবিত হয়েছে কিনা; যদি আপনার অ্যাপটি প্রভাবিত হয়ে থাকে, তাহলে এক্সিট রিজন হবে REASON_OTHER এবং ডেসক্রিপশনে অন্যান্য তথ্যের সাথে "MemoryLimiter:AnonSwap" স্ট্রিংটি থাকবে। এছাড়াও, মেমোরি লিমিট অতিক্রম করলে সংগৃহীত হিপ ডাম্প পেতে আপনি TRIGGER_TYPE_ANOMALY সহ ট্রিগার-ভিত্তিক প্রোফাইলিং ব্যবহার করতে পারেন।

আপনার অ্যাপের মেমরি পরিচালনা সংক্রান্ত ডকুমেন্টেশনটি আপনার অ্যাপের মেমরি সমস্যা নির্ণয় করতে এবং এর রিসোর্স ব্যবহার অপ্টিমাইজ করতে সাহায্য করার জন্য তথ্য প্রদান করে।

মেমরির সীমাবদ্ধতার অধীনে আপনার অ্যাপের আচরণ পরীক্ষা করুন

যেসব ডিভাইসে মেমরি লিমিট আরোপ করা হয়, সেগুলোর ক্ষেত্রে আপনি অ্যান্ড্রয়েড ডিবাগ ব্রিজ ( adb ) ব্যবহার করে তা সমন্বয় বা নিষ্ক্রিয় করতে পারেন। শেল কমান্ড am মেমরি লিমিট সমন্বয় করার জন্য তিনটি সাবকমান্ড প্রদান করে। (যেসব ডিভাইসে মেমরি লিমিট আরোপ করা হয় না, সেগুলোতে এই কমান্ডগুলোর কোনো প্রভাব নেই।)

• am memory-limiter ignore <uid>|none|all
• am memory-limiter manual <pid> <limit>|max|none
• am memory-limiter status

ignore

মেমরি লিমিটারকে কিছু বা সমস্ত প্রসেস উপেক্ষা করার নির্দেশ দেয়। একটি UID (অ্যান্ড্রয়েড ইউজার আইডি) পাস করলে, মেমরি লিমিটার সেই UID-এর সাথে যুক্ত সমস্ত প্রসেসের উপর বিধিনিষেধ আরোপ করা উপেক্ষা করে। আপনি all (সমস্ত অ্যাপ উপেক্ষা করতে) বা none (কোনো অ্যাপ উপেক্ষা না করতে) পাস করতে পারেন। none পাস করলে am memory-limiter ignore এর পূর্ববর্তী যেকোনো কল বাতিল হয়ে যায়।

আপনি যদি মেমরি লিমিটারকে কোনো UID উপেক্ষা করার নির্দেশ দেন, তারপরেও am memory-limiter manual কল করে অ্যাপের ভেতরের কোনো প্রসেসে ম্যানুয়ালি মেমরি লিমিট প্রয়োগ করতে পারবেন।

manual

সিস্টেমকে নির্দিষ্ট PID (প্রসেস আইডি) সহ প্রসেসটির উপর একটি মেমরি সীমাবদ্ধতা আরোপ করার নির্দেশ দেয়। মেমরি সীমাবদ্ধতাটি মেগাবাইটের (MB) একটি পূর্ণসংখ্যা হিসাবে নির্দিষ্ট করা হয়; উদাহরণস্বরূপ, 30 পাস করলে প্রসেসটি 30 মেগাবাইট মেমরিতে সীমাবদ্ধ থাকবে। max পাস করলে সেই প্রসেসের উপর থেকে সমস্ত মেমরি সীমাবদ্ধতা তুলে নেওয়া হয়। none পাস করলে প্রসেসটিতে সেট করা যেকোনো ম্যানুয়াল সীমাবদ্ধতা তুলে নেওয়া হয় এবং সিস্টেমের ডিফল্ট সীমাবদ্ধতা (যদি থাকে) পুনরুদ্ধার করা হয়।

status

মেমরি লিমিটারের বর্তমান অবস্থা রিপোর্ট করে। এই অবস্থায় দৃশ্যমান এবং অদৃশ্য প্রসেসগুলোর উপর আরোপিত মেমরি সীমা অন্তর্ভুক্ত থাকে।

গোপনীয়তা

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

এসএমএস ওটিপি সুরক্ষা

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অ্যান্ড্রয়েড ওয়ান-টাইম পাসওয়ার্ড (OTP) যুক্ত এসএমএস বার্তাগুলির সুরক্ষা আরও প্রসারিত করছে।

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

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

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

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

নিরাপত্তা

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

ক্লিয়ারট্র্যাফিক অবচয় পরিকল্পনা ব্যবহার করে

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

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

• usesCleartextTraffic অ্যাট্রিবিউটটি true তে সেট করুন।
• একটি নেটওয়ার্ক কনফিগারেশন ফাইল ব্যবহার করুন

যদি আপনার অ্যাপের সর্বনিম্ন API লেভেল 24 বা তার বেশি হয়, তাহলে আপনি একটি নেটওয়ার্ক কনফিগারেশন ফাইল ব্যবহার করতে পারেন এবং আপনার usesCleartextTraffic সেট করার প্রয়োজন নেই।

অন্তর্নিহিত URI অনুদান সীমাবদ্ধ করুন

বর্তমানে, যদি কোনো অ্যাপ ACTION_SEND , ACTION_SEND_MULTIPLE , বা ACTION_IMAGE_CAPTURE অ্যাকশনযুক্ত কোনো URI দিয়ে একটি ইন্টেন্ট চালু করে, তাহলে সিস্টেম স্বয়ংক্রিয়ভাবে টার্গেট অ্যাপটিকে URI-টি পড়া এবং লেখার অনুমতি দিয়ে দেয়। অ্যান্ড্রয়েড ১৮ থেকে, সিস্টেম আর স্বয়ংক্রিয়ভাবে এই অনুমতিগুলো দেবে না। এই কারণে, আমরা সুপারিশ করি যে অ্যাপগুলো যেন সিস্টেমের অনুমতির উপর নির্ভর না করে, সংশ্লিষ্ট URI-এর অনুমতিগুলো স্পষ্টভাবে প্রদান করে।

আপনার অ্যাপে এই ইন্টেন্টগুলির ব্যবহার শনাক্ত করতে, একটি ভায়োলেশন ট্রিগার করার জন্য detectImplicitUriPermissionGrant() সহ StrictMode ব্যবহার করুন:

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

বিকল্পভাবে, আপনি লগ করা এক্সেপশনগুলো মনিটর করতে পারেন, যেগুলোতে Please set the grant explicitly in the app বার্তাটি থাকে এবং যা সিস্টেম স্বয়ংক্রিয়ভাবে গ্রান্ট সেট করলে প্রদর্শিত হয়। আপনি নিম্নলিখিত adb কমান্ডটি ব্যবহার করে এই লগগুলো মনিটর করতে পারেন:

adb logcat | grep "Please set the grant explicitly in the app"

প্রয়োজনীয় অনুমতিগুলো স্পষ্টভাবে প্রদান করতে, ACTION_SEND এবং ACTION_SEND_MULTIPLE ইন্টেন্টগুলোতে FLAG_GRANT_READ_URI_PERMISSION ফ্ল্যাগটি যোগ করুন:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

ACTION_IMAGE_CAPTURE ইন্টেন্টগুলোর জন্য FLAG_GRANT_READ_URI_PERMISSION এবং FLAG_GRANT_WRITE_URI_PERMISSION উভয় ফ্ল্যাগ অন্তর্ভুক্ত করুন:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

প্রতি-অ্যাপ কীস্টোর সীমা

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

• Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
• All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

ক্রস প্রোফাইল লুপব্যাক ট্র্যাফিক ব্লক করুন

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

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

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

ঘূর্ণনের পরে ডিফল্ট IME দৃশ্যমানতা পুনরুদ্ধার করা হচ্ছে

Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.

If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:

• Set the android:windowSoftInputMode attribute to stateAlwaysVisible.
• Programmatically request the soft keyboard in your activity's onCreate() method, or add the onConfigurationChanged() method.

মানুষের ইনপুট

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

পয়েন্টার ক্যাপচারের সময় টাচপ্যাড ডিফল্টরূপে রিলেটিভ ইভেন্ট সরবরাহ করে।

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

পূর্বে, সিস্টেমটি টাচপ্যাড থেকে অঙ্গভঙ্গি শনাক্ত করার চেষ্টা করত না, এবং এর পরিবর্তে টাচস্ক্রিন স্পর্শের অনুরূপ বিন্যাসে অ্যাপে আঙুলের সরাসরি, পরম অবস্থান সরবরাহ করত। যদি কোনো অ্যাপের এখনও এই পরম ডেটার প্রয়োজন হয়, তবে তার পরিবর্তে নতুন View.requestPointerCapture(int) পদ্ধতিটি View.POINTER_CAPTURE_MODE_ABSOLUTE সহ কল ​​করা উচিত।

মিডিয়া

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

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

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

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

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

সংযোগ

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

ব্লুটুথ সংযোগ বিচ্ছিন্ন হলে স্বয়ংক্রিয়ভাবে পুনরায় জোড়া লাগানোর ব্যবস্থা

অ্যান্ড্রয়েড ১৭-এ স্বয়ংক্রিয় পুনঃ-পেয়ারিং (autonomous re-pairing) চালু করা হয়েছে, যা একটি সিস্টেম-স্তরের উন্নয়ন এবং ব্লুটুথ সংযোগ বিচ্ছিন্ন হয়ে গেলে তা স্বয়ংক্রিয়ভাবে সমাধান করার জন্য ডিজাইন করা হয়েছে।

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

যদিও বেশিরভাগ অ্যাপের জন্য কোডে কোনো পরিবর্তনের প্রয়োজন হবে না, ডেভেলপারদের ব্লুটুথ স্ট্যাকের নিম্নলিখিত আচরণগত পরিবর্তনগুলো সম্পর্কে সচেতন থাকা উচিত:

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

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

• পেরিফেরাল ডিভাইস থেকে বন্ডের তথ্য ম্যানুয়ালি মুছে ফেলুন
• সেটিংস > সংযুক্ত ডিভাইস-এ গিয়ে ডিভাইসটি ম্যানুয়ালি আনপেয়ার করুন।