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

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

目前，如果应用启动的 intent 具有 URI，且该 URI 具有操作 ACTION_SEND、ACTION_SEND_MULTIPLE或 ACTION_IMAGE_CAPTURE，则系统会自动向目标应用授予读取和 写入 URI 权限。从 Android 18 开始，系统将 不再自动授予这些权限。因此，我们建议应用明确授予相关 URI 权限，而不是依赖系统授予这些权限。

如需检测应用中这些 intent 的使用情况，请将 StrictMode 与 detectImplicitUriPermissionGrant() 结合使用，以触发违规行为：

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

或者，您也可以监控包含消息 Please set the grant explicitly in the app 的已记录异常，该消息会在系统隐式设置授予时显示。您可以使用以下 adb 命令监控这些日志：

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

如需明确授予必要的权限，请将 FLAG_GRANT_READ_URI_PERMISSION标志添加到ACTION_SEND和 ACTION_SEND_MULTIPLEintent：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

对于 ACTION_IMAGE_CAPTURE intent，请同时添加FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 标志：

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

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

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