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

অ্যান্ড্রয়েড ১৭ প্ল্যাটফর্মে এমন কিছু আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। 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) 连接的应用应迁移为使用网络安全配置文件，该文件可让您指定应用需要与哪些网域建立明文连接。

请注意，网络安全配置文件仅在 API 级别 24 及更高版本中受支持。如果您的应用的最低 API 级别低于 24，您应执行以下两项操作：

  • 将 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);

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

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

যদি কোনো অ্যাপ নির্ধারিত সীমার বাইরে কী তৈরি করার চেষ্টা করে, তাহলে KeyStoreException ত্রুটির কারণে কী তৈরি করা ব্যর্থ হয়। এক্সেপশনটির মেসেজ স্ট্রিং-এ কী-এর সীমা সম্পর্কিত তথ্য থাকে। যদি অ্যাপটি এক্সেপশনটির উপর getNumericErrorCode() কল করে, তাহলে রিটার্ন ভ্যালুটি নির্ভর করে অ্যাপটি কোন API লেভেলকে টার্গেট করছে তার উপর:

  • অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণের অ্যাপগুলোর ক্ষেত্রে: getNumericErrorCode() নতুন ERROR_TOO_MANY_KEYS ভ্যালুটি রিটার্ন করে।
  • অন্যান্য সকল অ্যাপের ক্ষেত্রে, getNumericErrorCode() ERROR_INCORRECT_USAGE রিটার্ন করে।

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

从 Android 17 开始，默认情况下不再允许跨个人资料环回流量。同一个人资料内的环回流量不受影响。 此项变更适用于在 Android 17 或更高版本上运行的所有应用，无论应用以哪个 API 级别为目标平台。

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

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

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

从 Android 17 开始，当设备的配置发生变化（例如，通过旋转）且应用本身未处理此变化时，系统不会恢复之前的 IME 可见性。

如果应用经历了它无法处理的配置更改，并且应用需要在更改后显示键盘，您必须明确请求此行为。您可以通过以下方式之一提出此要求：

  • 将 android:windowSoftInputMode 属性设置为 stateAlwaysVisible。
  • 在 activity 的 onCreate() 方法中以编程方式请求显示软键盘，或添加 onConfigurationChanged() 方法。

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

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

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

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, যদি কোনো অ্যাপ 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 বিজ্ঞপ্তি এবং ডায়ালগের মাধ্যমে পুনরায় পেয়ারিং পরিচালনা করে। ব্যবহারকারীরা যাতে পুনরায় সংযোগের বিষয়ে অবগত হন, তা নিশ্চিত করার জন্য তাদেরকে পুনরায় পেয়ারিং প্রচেষ্টাটি নিশ্চিত করতে অনুরোধ করা হবে।

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

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