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

অ্যান্ড্রয়েড ১৭ প্ল্যাটফর্মে এমন কিছু আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। 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

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

গোপনীয়তা

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

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

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

নিরাপত্তা

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

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

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

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

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

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

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

Currently, if an app launches an intent with a URI that has the action ACTION_SEND, ACTION_SEND_MULTIPLE, or ACTION_IMAGE_CAPTURE, the system automatically grants the read and write URI permissions to the target app. Starting in Android 18, the system will no longer automatically grant these permissions. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

To detect the usage of these intents in your app, use StrictMode with detectImplicitUriPermissionGrant() to trigger a violation:

Kotlin

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

Java

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

Alternatively, you can monitor for logged exceptions containing the message Please set the grant explicitly in the app that appears when system implicitly sets the grant. You can monitor for these logs using the following adb command:

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

To explicitly grant the necessary permissions, add the FLAG_GRANT_READ_URI_PERMISSION flag to ACTION_SEND and ACTION_SEND_MULTIPLE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Include both FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags for ACTION_IMAGE_CAPTURE intents:

Kotlin

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

Java

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 রিটার্ন করে।

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

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

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

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

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

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

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

  • android:windowSoftInputMode অ্যাট্রিবিউটটিকে stateAlwaysVisible এ সেট করুন।
  • আপনার অ্যাক্টিভিটির 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 বিজ্ঞপ্তি এবং ডায়ালগের মাধ্যমে পুনরায় পেয়ারিং পরিচালনা করে। ব্যবহারকারীরা যাতে পুনরায় সংযোগের বিষয়ে অবগত হন, তা নিশ্চিত করার জন্য তাদেরকে পুনরায় পেয়ারিং প্রচেষ্টাটি নিশ্চিত করতে অনুরোধ করা হবে।

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

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