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

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

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

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

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

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

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

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

অ্যান্ড্রয়েড স্টুডিও প্রোফাইলারের LeakCanary টাস্ক।

মেমরি লিক খুঁজে পেতে আপনাকে সাহায্য করার জন্য, অ্যান্ড্রয়েড স্টুডিও পান্ডা সরাসরি অ্যান্ড্রয়েড স্টুডিও প্রোফাইলারের মধ্যে একটি ডেডিকেটেড টাস্ক হিসেবে লিকক্যানারি ইন্টিগ্রেশন যুক্ত করে, যা IDE-এর মধ্যেই প্রাসঙ্গিক থাকে এবং আপনার সোর্স কোডের সাথে সম্পূর্ণরূপে সমন্বিত হয়।

গোপনীয়তা

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

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

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অ্যান্ড্রয়েড ওয়ান-টাইম পাসওয়ার্ড (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);

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

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

যদি কোনো অ্যাপ নির্ধারিত সীমার বাইরে কী তৈরি করার চেষ্টা করে, তাহলে 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 সহ কল ​​করা উচিত।

মিডিয়া

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

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

从 Android 17 开始，音频框架会对后台音频互动（包括音频播放、音频焦点请求和音量更改 API）强制执行限制，以确保这些更改是由用户有意发起的。

如果应用尝试在应用未处于有效生命周期时调用音频 API，则音频播放和音量更改 API 会以静默方式失败，而不会抛出异常或提供失败消息。音频焦点 API 会失败，并返回结果代码 AUDIOFOCUS_REQUEST_FAILED。

如需了解详情（包括缓解措施），请参阅后台音频安全加固。

সংযোগ

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

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

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

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

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

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

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

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