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

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

এছাড়াও, Android 17-কে টার্গেট করা অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকা পর্যালোচনা করতে ভুলবেন না।

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

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

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

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

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

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

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

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

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

ignore

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

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

manual

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

status

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

গোপনীয়তা

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

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

Android 17 থেকে শুরু করে, Android, একবার ব্যবহারের পাসওয়ার্ড (OTP) সহ এসএমএস মেসেজের জন্য সুরক্ষা আরও বাড়াচ্ছে।

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

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

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

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

নিরাপত্তা

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

usesClearTraffic বন্ধ করার প্ল্যান

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

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

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

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

ইমপ্লিসিট URI গ্র্যান্টের উপর বিধিনিষেধ আরোপ করুন

বর্তমানে, কোনও অ্যাপ যদি এমন URI সহ ইনটেন্ট লঞ্চ করে যার অ্যাকশন ACTION_SEND, ACTION_SEND_MULTIPLE, অথবা ACTION_IMAGE_CAPTURE, তাহলে সিস্টেম অটোমেটিক টার্গেট অ্যাপকে URI রিড ও রাইট করার অনুমতি দেয়। Android 18 থেকে, সিস্টেম আর অটোমেটিক এইসব অনুমতি দেবে না। এই কারণে, আমরা সাজেস্ট করি যে অ্যাপগুলি যেন সিস্টেমের উপর নির্ভর না করে সরাসরি প্রাসঙ্গিক URI অনুমতি প্রদান করে।

আপনার অ্যাপে এইসব ইনটেন্টের ব্যবহার শনাক্ত করতে, StrictMode-এর সাথে detectImplicitUriPermissionGrant() ব্যবহার করে লঙ্ঘন ট্রিগার করুন:

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

প্রতি অ্যাপে Keystore-এর সীমা

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

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

• Android 17 (API লেভেল 37) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করা অ্যাপ: getNumericErrorCode() নতুন ERROR_TOO_MANY_KEYS ভ্যালু রিটার্ন করে।
• অন্যান্য সব অ্যাপ: getNumericErrorCode()-এর রিটার্ন ERROR_INCORRECT_USAGE।

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

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

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

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

ঘোরানোর পরে ডিফল্ট IME দৃশ্যমানতা ফিরিয়ে আনা হচ্ছে

Android 17 থেকে শুরু করে, ডিভাইসের কনফিগারেশন পরিবর্তন হলে (যেমন, ঘোরানোর মাধ্যমে) এবং এটি অ্যাপ নিজে থেকে ম্যানেজ না করলে, আগের IME দৃশ্যমানতা ফিরিয়ে আনা হয় না।

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

• android:windowSoftInputMode অ্যাট্রিবিউট stateAlwaysVisible-এ সেট করুন।
• আপনার অ্যাক্টিভিটির onCreate() পদ্ধতিতে প্রোগ্রাম্যাটিক্যালি সফ্ট কীবোর্ডের অনুরোধ করুন অথবা onConfigurationChanged() পদ্ধতি যোগ করুন।

হিউম্যান ইনপুট

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

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

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

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

মিডিয়া

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

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

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

অ্যাপটি সঠিক লাইফসাইকেলে না থাকা অবস্থায় অডিও API কল করার চেষ্টা করলে, অডিও প্লেব্যাক এবং ভলিউম পরিবর্তন API কোনও ব্যতিক্রম না দেখিয়ে বা ব্যর্থতার মেসেজ না দিয়ে নীরবে ব্যর্থ হয়। অডিও ফোকাস API, AUDIOFOCUS_REQUEST_FAILED ফলাফল কোড সহ ব্যর্থ হয়েছে।

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

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

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

ব্লুটুথ বন্ড লসের জন্য অটোনোমাস রি-পেয়ারিং

Android 17-এ অটোনোমাস রি-পেয়ারিং ফিচার নিয়ে আসা হয়েছে, এটি সিস্টেম-লেভেল এনহ্যান্সমেন্ট যা ব্লুটুথ বন্ড লস অটোমেটিক সমাধান করার জন্য ডিজাইন করা হয়েছে।

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

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

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

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

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