আচরণের পরিবর্তন: Android 16 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপ

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

আপনার অ্যাপের targetSdkVersion নির্বিশেষে Android 16-এ চালিত সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।

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

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

এজ-টু-এজ অপ্ট-আউট বন্ধ হয়ে যাচ্ছে

অ্যান্ড্রয়েড ১৫-এর জন্য তৈরি অ্যাপগুলোর (এপিআই লেভেল ৩৫) ক্ষেত্রে এজ-টু-এজ ইন্টিগ্রেশন বাধ্যতামূলক করা হয়েছিল , কিন্তু আপনার অ্যাপ R.attr#windowOptOutEdgeToEdgeEnforcement true সেট করে এটি থেকে অপ্ট-আউট করতে পারত। অ্যান্ড্রয়েড ১৬-এর জন্য তৈরি অ্যাপগুলোর (এপিআই লেভেল ৩৬) ক্ষেত্রে, R.attr#windowOptOutEdgeToEdgeEnforcement এখন আর ব্যবহৃত হয় না এবং নিষ্ক্রিয় করা আছে, এবং আপনার অ্যাপ এজ-টু-এজ ইন্টিগ্রেশন থেকে অপ্ট-আউট করতে পারবে না।

• আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) টার্গেট করে তৈরি হয় এবং একটি অ্যান্ড্রয়েড ১৫ ডিভাইসে চলে, R.attr#windowOptOutEdgeToEdgeEnforcement কাজ করতে থাকবে।
• আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) টার্গেট করে তৈরি হয় এবং কোনো অ্যান্ড্রয়েড ১৬ ডিভাইসে চলে, R.attr#windowOptOutEdgeToEdgeEnforcement নিষ্ক্রিয় হয়ে যায়।

অ্যান্ড্রয়েড ১৬-এ পরীক্ষার জন্য, নিশ্চিত করুন যে আপনার অ্যাপটি এজ-টু-এজ সমর্থন করে এবং R.attr#windowOptOutEdgeToEdgeEnforcement এর যেকোনো ব্যবহার সরিয়ে ফেলুন, যাতে আপনার অ্যাপটি অ্যান্ড্রয়েড ১৫ ডিভাইসেও এজ-টু-এজ সমর্থন করে। এজ-টু-এজ সমর্থন করার জন্য, Compose এবং Views নির্দেশিকা দেখুন।

ভবিষ্যদ্বাণীমূলক ব্যাকআপের জন্য মাইগ্রেশন বা অপ্ট-আউট প্রয়োজন।

যেসব অ্যাপ অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) বা তার উচ্চতর সংস্করণকে টার্গেট করে এবং অ্যান্ড্রয়েড ১৬ বা তার উচ্চতর সংস্করণের ডিভাইসে চলে, সেগুলোর ক্ষেত্রে প্রেডিক্টিভ ব্যাক সিস্টেম অ্যানিমেশনগুলো (ব্যাক-টু-হোম, ক্রস-টাস্ক, এবং ক্রস-অ্যাক্টিভিটি) ডিফল্টরূপে সক্রিয় থাকে। এছাড়াও, onBackPressed কল করা হয় না এবং KeyEvent.KEYCODE_BACK আর ডিসপ্যাচ করা হয় না।

যদি আপনার অ্যাপ ব্যাক ইভেন্ট ইন্টারসেপ্ট করে এবং আপনি এখনও প্রেডিক্টিভ ব্যাক-এ মাইগ্রেট না করে থাকেন, তাহলে সমর্থিত ব্যাক নেভিগেশন API ব্যবহার করার জন্য আপনার অ্যাপটি আপডেট করুন , অথবা আপনার অ্যাপের AndroidManifest.xml ফাইলের <application> বা <activity> ট্যাগে android:enableOnBackInvokedCallback অ্যাট্রিবিউটটিকে false সেট করে সাময়িকভাবে এটি থেকে বিরত থাকুন।

মার্জিত ফন্ট এপিআইগুলি অপ্রচলিত এবং নিষ্ক্রিয় করা হয়েছে।

অ্যান্ড্রয়েড 15 (API স্তর 35) টার্গেট করা অ্যাপগুলির মধ্যে elegantTextHeight TextView বৈশিষ্ট্যটি ডিফল্টভাবে true হিসাবে সেট করা আছে, কমপ্যাক্ট ফন্টটিকে এমন একটি দিয়ে প্রতিস্থাপন করা যা অনেক বেশি পাঠযোগ্য। আপনি elegantTextHeight অ্যাট্রিবিউটটি false সেট করে এটিকে ওভাররাইড করতে পারেন।

অ্যান্ড্রয়েড 16 elegantTextHeight অ্যাট্রিবিউটকে অবমূল্যায়ন করে, এবং আপনার অ্যাপটি Android 16 কে লক্ষ্য করলে অ্যাট্রিবিউটটি উপেক্ষা করা হবে। এই APIগুলির দ্বারা নিয়ন্ত্রিত "UI ফন্টগুলি" বন্ধ করা হচ্ছে, তাই আরবি, লাও, মায়ানমার, গুজরাটি, মায়ানমার, মালাগুজরাতি, মালায়ানা, মালাগুজরা, মায়ানমার, মালাগুজরা, মায়ানমার, টেক্সট টেক্সট রেন্ডারিং সামঞ্জস্যপূর্ণ এবং ভবিষ্যতের প্রুফ টেক্সট রেন্ডারিং নিশ্চিত করতে আপনার যেকোনো লেআউটকে মানিয়ে নেওয়া উচিত। থাই।

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

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

স্থির হারে কাজের সময়সূচী অপ্টিমাইজেশন

Android 16 টার্গেট করার আগে, যখন scheduleAtFixedRate একটি বৈধ প্রক্রিয়া লাইফসাইকেলের বাইরে থাকার কারণে একটি টাস্ক এক্সিকিউশন মিস করে, অ্যাপটি একটি বৈধ লাইফসাইকেলে ফিরে গেলে সমস্ত মিস করা এক্সিকিউশন অবিলম্বে কার্যকর হয়।

অ্যান্ড্রয়েড 16-কে টার্গেট করার সময়, অ্যাপটি একটি বৈধ জীবনচক্রে ফিরে এলে scheduleAtFixedRate সর্বাধিক একটি মিস করা কার্যকর করা হয়। এই আচরণ পরিবর্তন অ্যাপের কর্মক্ষমতা উন্নত করবে বলে আশা করা হচ্ছে। আপনার অ্যাপ প্রভাবিত হয়েছে কিনা তা পরীক্ষা করতে আপনার অ্যাপে এই আচরণ পরীক্ষা করুন। এছাড়াও আপনি অ্যাপের সামঞ্জস্যতা ফ্রেমওয়ার্ক ব্যবহার করে এবং STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS কম্প্যাট পতাকা সক্ষম করে পরীক্ষা করতে পারেন।

ডিভাইসের ফর্ম ফ্যাক্টর

অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬)-এ বড় স্ক্রিনের ডিভাইসে অ্যাপ প্রদর্শনের ক্ষেত্রে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

অভিযোজিত বিন্যাস

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

অভিমুখ, আকার পরিবর্তনযোগ্যতা এবং আকৃতি অনুপাতের সীমাবদ্ধতা উপেক্ষা করুন

অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) টার্গেট করা অ্যাপগুলোর ক্ষেত্রে, সর্বনিম্ন প্রস্থ >= ৬০০ডিপি (dp) যুক্ত ডিসপ্লেতে ওরিয়েন্টেশন, রিসাইজযোগ্যতা এবং অ্যাসপেক্ট রেশিওর সীমাবদ্ধতা আর প্রযোজ্য হবে না। অ্যাপগুলো অ্যাসপেক্ট রেশিও বা ব্যবহারকারীর পছন্দের ওরিয়েন্টেশন নির্বিশেষে সম্পূর্ণ ডিসপ্লে উইন্ডো জুড়ে থাকবে এবং পিলরবক্সিং ব্যবহৃত হবে না।

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

আপনি অ্যাপ কম্প্যাটিবিলিটি ফ্রেমওয়ার্ক ব্যবহার করে এবং UNIVERSAL_RESIZABLE_BY_DEFAULT কম্প্যাট ফ্ল্যাগটি সক্রিয় করার মাধ্যমেও এই আচরণটি পরীক্ষা করতে পারেন।

সাধারণ ব্রেকিং পরিবর্তনগুলি

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

ডিভাইস ঘোরানোর অনুমতি দিলে অ্যাক্টিভিটি বারবার তৈরি হয়, যা সঠিকভাবে সংরক্ষণ করা না হলে ইউজার স্টেট হারিয়ে যাওয়ার কারণ হতে পারে। কীভাবে UI স্টেট সঠিকভাবে সংরক্ষণ করতে হয়, তা জানতে "Save UI states" অংশটি দেখুন।

বাস্তবায়নের বিবরণ

বড় স্ক্রিনের ডিভাইসগুলিতে ফুল-স্ক্রিন এবং মাল্টি-উইন্ডো মোডে নিম্নলিখিত ম্যানিফেস্ট অ্যাট্রিবিউট এবং রানটাইম এপিআইগুলি উপেক্ষা করা হয়:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

screenOrientation , setRequestedOrientation() , এবং getRequestedOrientation() এর নিম্নলিখিত মানগুলি উপেক্ষা করা হয়:

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

ডিসপ্লে রিসাইজ করার ক্ষেত্রে, android:resizeableActivity="false" , android:minAspectRatio , এবং android:maxAspectRatio কোনো প্রভাব নেই।

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

ব্যতিক্রম

অ্যান্ড্রয়েড ১৬-এর ওরিয়েন্টেশন, রিসাইজযোগ্যতা এবং অ্যাসপেক্ট রেশিও সংক্রান্ত সীমাবদ্ধতাগুলো নিম্নলিখিত পরিস্থিতিগুলোতে প্রযোজ্য নয়:

• গেমস ( android:appCategory ফ্ল্যাগের উপর ভিত্তি করে)
• ডিভাইসের অ্যাস্পেক্ট রেশিও সেটিংসে ব্যবহারকারীরা অ্যাপটির ডিফল্ট আচরণ স্পষ্টভাবে বেছে নিলে
• sw600dp এর চেয়ে ছোট স্ক্রিন

সাময়িকভাবে অপ্ট আউট করুন

কোনো নির্দিষ্ট কার্যকলাপ থেকে অপ্ট-আউট করতে, PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY ম্যানিফেস্ট প্রপার্টিটি ডিক্লেয়ার করুন:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

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

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

স্বাস্থ্য ও ফিটনেস

অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬)-এ স্বাস্থ্য ও ফিটনেস ডেটা সম্পর্কিত নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

স্বাস্থ্য ও ফিটনেস অনুমতি

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用， BODY_SENSORS 权限使用更精细的权限 under android.permissions.health，which Health Connect also uses。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• HEART_RATE_BPM Wear OS 上的健康服务
• Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
• heartRateAccuracy 和 heartRateBpm（来自 Wear OS 上的 ProtoLayout）
• FOREGROUND_SERVICE_TYPE_HEALTH ，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 如需在使用期间监测心率、血氧饱和度或体表温度： 请请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 如需访问后台传感器，请请求 READ_HEALTH_DATA_IN_BACKGROUND，而不是 BODY_SENSORS_BACKGROUND。

这些权限与保护对 Health Connect（用于存储健康、 健身和保健数据的 Android 数据存储区）中数据的读取访问权限的权限相同。

移动应用

迁移为使用 READ_HEART_RATE 和其他精细权限的移动应用还必须 声明一项 activity 以显示应用的隐私权政策。这与健康数据共享的要求相同。

সংযোগ

পেরিফেরাল ডিভাইসগুলোর সাথে সংযোগ উন্নত করার জন্য অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬)-এর ব্লুটুথ স্ট্যাকে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

বন্ড ক্ষতি এবং এনক্রিপশন পরিবর্তনগুলি পরিচালনা করার জন্য নতুন উদ্দেশ্য

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

ব্লুটুথ বন্ড অপসারণের নতুন উপায়

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

নিরাপত্তা

অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬)-এ নিম্নলিখিত নিরাপত্তা পরিবর্তনগুলো অন্তর্ভুক্ত রয়েছে।

মিডিয়াস্টোর সংস্করণ লকডাউন

অ্যান্ড্রয়েড 16 বা তার বেশির দিকের অ্যাপ্লিকেশানগুলির জন্য, MediaStore#getVersion() এখন প্রতিটি অ্যাপের জন্য অনন্য হবে৷ এটি ফিঙ্গারপ্রিন্টিং কৌশলগুলির অপব্যবহার এবং ব্যবহার রোধ করতে সংস্করণ স্ট্রিং থেকে বৈশিষ্ট্যগুলি সনাক্তকরণকে সরিয়ে দেয়। অ্যাপগুলিকে এই সংস্করণের বিন্যাসের চারপাশে কোনো অনুমান করা উচিত নয়। এই API ব্যবহার করার সময় অ্যাপগুলির ইতিমধ্যেই সংস্করণ পরিবর্তনগুলি পরিচালনা করা উচিত এবং বেশিরভাগ ক্ষেত্রে তাদের বর্তমান আচরণ পরিবর্তন করার প্রয়োজন হবে না, যদি না বিকাশকারী অতিরিক্ত তথ্য অনুমান করার চেষ্টা না করে যা এই API এর উদ্দেশ্যের বাইরে।

নিরাপদ উদ্দেশ্য

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

অ্যান্ড্রয়েড ১৫- এ এই ফিচারটি প্রেরক অ্যাপকে কেন্দ্র করে তৈরি হয়েছিল। এখন অ্যান্ড্রয়েড ১৬-তে নিয়ন্ত্রণ প্রাপক অ্যাপের হাতে চলে গেছে, যা ডেভেলপারদের তাদের অ্যাপ ম্যানিফেস্ট ব্যবহার করে কঠোর ইনটেন্ট রেজোলিউশন বেছে নেওয়ার সুযোগ করে দিয়েছে।

দুটি গুরুত্বপূর্ণ পরিবর্তন বাস্তবায়ন করা হচ্ছে:

1. সুস্পষ্ট ইনটেন্ট অবশ্যই টার্গেট কম্পোনেন্টের ইনটেন্ট ফিল্টারের সাথে মিলতে হবে: যদি কোনো ইনটেন্ট সুস্পষ্টভাবে কোনো কম্পোনেন্টকে টার্গেট করে, তবে সেটিকে অবশ্যই সেই কম্পোনেন্টের ইনটেন্ট ফিল্টারের সাথে মিলতে হবে।

2. অ্যাকশনবিহীন ইন্টেন্ট কোনো ইন্টেন্ট ফিল্টারের সাথে মেলানো যাবে না: যেসব ইন্টেন্টে কোনো অ্যাকশন নির্দিষ্ট করা নেই, সেগুলোকে কোনো ইন্টেন্ট ফিল্টারে সমাধান করা উচিত নয়।

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

প্রভাব

অপ্ট-ইন প্রকৃতির হওয়ায়, এটি কার্যকর করার জন্য ডেভেলপারদের অবশ্যই তাদের অ্যাপ ম্যানিফেস্টে এটি স্পষ্টভাবে সক্রিয় করতে হবে। ফলস্বরূপ, এই ফিচারটির প্রভাব সেইসব অ্যাপের মধ্যেই সীমাবদ্ধ থাকবে, যাদের ডেভেলপাররা:

• সেফার ইনটেন্টস ফিচার এবং এর সুবিধাগুলো সম্পর্কে অবগত আছেন।
• তারা সক্রিয়ভাবে তাদের অ্যাপে আরও কঠোর ইনটেন্ট হ্যান্ডলিং পদ্ধতি অন্তর্ভুক্ত করার সিদ্ধান্ত নেয়।

এই অপ্ট-ইন পদ্ধতিটি এমন বিদ্যমান অ্যাপগুলো ভেঙে যাওয়ার ঝুঁকি কমিয়ে দেয়, যেগুলো বর্তমান কম-সুরক্ষিত ইনটেন্ট রেজোলিউশন আচরণের উপর নির্ভর করতে পারে।

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

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

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

বাস্তবায়ন

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

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

সমর্থিত ফ্ল্যাগগুলো সম্পর্কে আরও তথ্য:

পরীক্ষা এবং ডিবাগিং

যখন এই নিয়মটি সক্রিয় থাকে, তখন যদি ইন্টেন্ট কলার সঠিকভাবে ইন্টেন্টটি পূরণ করে থাকে, তবে অ্যাপগুলো ঠিকঠাক কাজ করার কথা। তবে, ব্লক করা ইন্টেন্টগুলো "PackageManager" ট্যাগসহ "Intent does not match component's intent filter:" এবং "Access blocked:" এর মতো সতর্কতামূলক লগ বার্তা দেখাবে "PackageManager." এটি একটি সম্ভাব্য সমস্যার ইঙ্গিত দেয় যা অ্যাপটিকে প্রভাবিত করতে পারে এবং এর প্রতি মনোযোগ দেওয়া প্রয়োজন।

লগক্যাট ফিল্টার:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

জিপিইউ সিস্টেম কল ফিল্টারিং

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

এই পরিবর্তনটি মালি জিপিইউ (Mali GPU) ব্যবহারকারী পিক্সেল ডিভাইসগুলিতে (পিক্সেল ৬-৯) কার্যকর হবে। আর্ম (Arm) তাদের r54p2 রিলিজের Documentation/ioctl-categories.rst ফাইলে তাদের IOCTL-গুলোর আনুষ্ঠানিক শ্রেণিবিন্যাস প্রদান করেছে। ভবিষ্যতের ড্রাইভার রিলিজগুলোতেও এই তালিকাটি রক্ষণাবেক্ষণ করা অব্যাহত থাকবে।

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

পরীক্ষা

আপনি যদি নিম্নলিখিতের মতো কোনো SELinux অস্বীকৃতি দেখতে পান, তাহলে সম্ভবত আপনার অ্যাপ্লিকেশনটি এই পরিবর্তনের দ্বারা প্রভাবিত হয়েছে:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

আপনার অ্যাপ্লিকেশনে যদি ব্লক করা IOCTL ব্যবহার করার প্রয়োজন হয়, তাহলে অনুগ্রহ করে একটি বাগ রিপোর্ট ফাইল করুন এবং android-partner-security@google.com-এ অ্যাসাইন করুন।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

1. এই নীতি পরিবর্তনটি কি সকল OEM-এর জন্য প্রযোজ্য? এই পরিবর্তনটি ঐচ্ছিক হবে, তবে যে সকল OEM এই হার্ডেনিং পদ্ধতিটি ব্যবহার করতে ইচ্ছুক, তারা এটি গ্রহণ করতে পারবেন। পরিবর্তনটি বাস্তবায়নের নির্দেশাবলী ইমপ্লিমেন্টেশন ডকুমেন্টেশনে পাওয়া যাবে।

2. এটি বাস্তবায়নের জন্য OEM কোডবেসে পরিবর্তন আনা কি বাধ্যতামূলক, নাকি এটি নতুন AOSP রিলিজের সাথে ডিফল্টভাবে চলে আসে? প্ল্যাটফর্ম-স্তরের পরিবর্তনটি নতুন AOSP রিলিজের সাথে ডিফল্টভাবে চলে আসবে। ভেন্ডররা চাইলে তাদের কোডবেসে এই পরিবর্তনটি অন্তর্ভুক্ত করতে পারেন।

3. SoC-গুলো কি IOCTL তালিকা হালনাগাদ রাখার জন্য দায়ী? উদাহরণস্বরূপ, যদি আমার ডিভাইসটি একটি ARM Mali GPU ব্যবহার করে, তাহলে কোনো পরিবর্তনের জন্য কি আমাকে ARM-এর সাথে যোগাযোগ করতে হবে? ড্রাইভার প্রকাশের সাথে সাথে প্রতিটি SoC-কে তাদের ডিভাইসের জন্য IOCTL তালিকা হালনাগাদ করতে হবে। উদাহরণস্বরূপ, ARM ড্রাইভার আপডেটের সময় তাদের প্রকাশিত IOCTL তালিকা হালনাগাদ করবে। তবে, OEM-দের নিশ্চিত করতে হবে যে তারা তাদের SEPolicy-তে এই আপডেটগুলো অন্তর্ভুক্ত করেছে এবং প্রয়োজন অনুযায়ী নির্বাচিত কাস্টম IOCTL-গুলো তালিকায় যুক্ত করেছে।

4. এই পরিবর্তনটি কি বাজারে থাকা সমস্ত পিক্সেল ডিভাইসে স্বয়ংক্রিয়ভাবে প্রযোজ্য হবে, নাকি এই পরিবর্তনটি প্রয়োগ করার জন্য ব্যবহারকারীকে কিছু টগল করতে হবে? এই পরিবর্তনটি মালি জিপিইউ (Mali GPU) ব্যবহারকারী বাজারে থাকা সমস্ত পিক্সেল ডিভাইসে (পিক্সেল ৬-৯) প্রযোজ্য হবে। এই পরিবর্তনটি প্রয়োগ করার জন্য ব্যবহারকারীর কোনো পদক্ষেপের প্রয়োজন নেই।

5. এই পলিসির ব্যবহার কি কার্নেল ড্রাইভারের পারফরম্যান্সে প্রভাব ফেলবে? এই পলিসিটি GFXBench ব্যবহার করে মালি জিপিইউ-তে পরীক্ষা করা হয়েছিল এবং জিপিইউ পারফরম্যান্সে কোনো পরিমাপযোগ্য পরিবর্তন লক্ষ্য করা যায়নি।

6. IOCTL তালিকাটিকে বর্তমান ইউজারস্পেস এবং কার্নেল ড্রাইভার সংস্করণের সাথে সামঞ্জস্যপূর্ণ রাখা কি আবশ্যক? হ্যাঁ, অনুমোদিত IOCTL-এর তালিকাটি অবশ্যই ইউজারস্পেস এবং কার্নেল ড্রাইভার উভয়ের দ্বারা সমর্থিত IOCTL-এর সাথে সিঙ্ক্রোনাইজড হতে হবে। যদি ইউজারস্পেস বা কার্নেল ড্রাইভারের IOCTL-গুলো আপডেট করা হয়, তবে SEPolicy IOCTL তালিকাটিকেও তার সাথে মিলিয়ে আপডেট করতে হবে।

7. ARM, IOCTL-গুলোকে 'সীমাবদ্ধ' / 'ইনস্ট্রুমেন্টেশন' হিসেবে শ্রেণীবদ্ধ করেছে, কিন্তু আমরা সেগুলোর কয়েকটি প্রোডাকশন ব্যবহারের ক্ষেত্রে ব্যবহার করতে চাই এবং/অথবা অন্যগুলো বাদ দিতে চাই। প্রতিটি OEM/SoC তাদের ইউজারস্পেস মালি লাইব্রেরির কনফিগারেশনের উপর ভিত্তি করে, তারা যে IOCTL-গুলো ব্যবহার করে সেগুলোকে কীভাবে শ্রেণীবদ্ধ করবে, সেই সিদ্ধান্ত নেওয়ার দায়িত্ব তাদেরই। এই বিষয়ে সিদ্ধান্ত নিতে ARM-এর তালিকাটি সাহায্য করতে পারে, কিন্তু প্রতিটি OEM/SoC-এর ব্যবহারের ক্ষেত্র ভিন্ন হতে পারে।

গোপনীয়তা

অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬)-এ নিম্নলিখিত গোপনীয়তা পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

স্থানীয় নেটওয়ার্ক অনুমতি

LAN-এ থাকা ডিভাইসগুলো এমন যেকোনো অ্যাপ দ্বারা অ্যাক্সেস করা যায়, যার INTERNET পারমিশন আছে। এর ফলে অ্যাপগুলোর পক্ষে স্থানীয় ডিভাইসগুলোর সাথে সংযোগ স্থাপন করা সহজ হয়ে যায়, কিন্তু এর গোপনীয়তার ক্ষেত্রেও কিছু ঝুঁকি রয়েছে, যেমন—ব্যবহারকারীর ফিঙ্গারপ্রিন্ট তৈরি হওয়া এবং অবস্থানের প্রক্সি হিসেবে কাজ করা।

লোকাল নেটওয়ার্ক প্রোটেকশনস প্রকল্পের লক্ষ্য হলো একটি নতুন রানটাইম পারমিশনের মাধ্যমে লোকাল নেটওয়ার্কে প্রবেশাধিকার সীমিত করে ব্যবহারকারীর গোপনীয়তা রক্ষা করা।

মুক্তির পরিকল্পনা

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

প্রভাব

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

অ্যাপগুলি নিম্নলিখিত উপায়ে ব্যবহারকারীর লোকাল নেটওয়ার্ক অ্যাক্সেস করলে প্রভাবিত হবে:

• স্থানীয় নেটওয়ার্ক অ্যাড্রেসে র সকেটের সরাসরি বা লাইব্রেরি ব্যবহার (যেমন mDNS বা SSDP সার্ভিস ডিসকভারি প্রোটোকল)
• ফ্রেমওয়ার্ক স্তরের ক্লাসগুলির ব্যবহার যেগুলো স্থানীয় নেটওয়ার্ক অ্যাক্সেস করে (যেমন NsdManager)

একটি স্থানীয় নেটওয়ার্ক ঠিকানায় আসা - যাওয়ার জন্য স্থানীয় নেটওয়ার্ক অ্যাক্সেসের অনুমতি প্রয়োজন। নিম্নলিখিত সারণিতে কিছু সাধারণ ক্ষেত্র তালিকাভুক্ত করা হলো:

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

উপরোক্ত নিয়মগুলির ব্যতিক্রম:

• যদি কোনো ডিভাইসের ডিএনএস সার্ভার লোকাল নেটওয়ার্কে থাকে, তবে সেটিতে (পোর্ট ৫৩-এ) আসা-যাওয়ার ট্র্যাফিকের জন্য লোকাল নেটওয়ার্ক অ্যাক্সেস পারমিশনের প্রয়োজন হয় না।
• যেসব অ্যাপ্লিকেশন তাদের ইন-অ্যাপ পিকার হিসেবে আউটপুট সুইচার ব্যবহার করে, সেগুলোর জন্য লোকাল নেটওয়ার্ক পারমিশনের প্রয়োজন হবে না (২০২৫ সালের চতুর্থ ত্রৈমাসিকে এ বিষয়ে আরও নির্দেশনা জানানো হবে)।

ডেভেলপারদের জন্য নির্দেশিকা (ঐচ্ছিক)

স্থানীয় নেটওয়ার্ক বিধিনিষেধ চালু করতে, নিম্নলিখিতগুলি করুন:

1. ডিভাইসটিকে 25Q2 Beta 3 বা তার পরবর্তী সংস্করণের কোনো বিল্ডে ফ্ল্যাশ করুন।
2. পরীক্ষা করার জন্য অ্যাপটি ইনস্টল করুন।

3. adb-তে Appcompat ফ্ল্যাগটি টগল করুন:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. ডিভাইসটি রিবুট করুন

এখন আপনার অ্যাপের লোকাল নেটওয়ার্কে প্রবেশাধিকার সীমাবদ্ধ করা হয়েছে এবং লোকাল নেটওয়ার্ক অ্যাক্সেস করার যেকোনো প্রচেষ্টার ফলে সকেট এরর দেখা দেবে। আপনি যদি এমন কোনো এপিআই (API) ব্যবহার করেন যা আপনার অ্যাপ প্রসেসের বাইরে লোকাল নেটওয়ার্ক অপারেশন সম্পাদন করে (যেমন: NsdManager), তবে অপ্ট-ইন পর্ব চলাকালীন সেগুলোর ওপর কোনো প্রভাব পড়বে না।

অ্যাক্সেস পুনরুদ্ধার করতে, আপনাকে অবশ্যই আপনার অ্যাপকে NEARBY_WIFI_DEVICES এর জন্য অনুমতি প্রদান করতে হবে।

1. নিশ্চিত করুন যে অ্যাপটি তার ম্যানিফেস্টে NEARBY_WIFI_DEVICES পারমিশনটি ঘোষণা করেছে।
2. সেটিংস > অ্যাপস > [অ্যাপ্লিকেশনের নাম] > অনুমতি > কাছাকাছি ডিভাইস > অনুমতি দিন -এ যান।

এখন আপনার অ্যাপের লোকাল নেটওয়ার্কে অ্যাক্সেস পুনরুদ্ধার হওয়া উচিত এবং আপনার সমস্ত সিনারিও অ্যাপটি অপ্ট-ইন করার আগের মতোই কাজ করা উচিত।

স্থানীয় নেটওয়ার্ক সুরক্ষা কার্যকর হওয়া শুরু হলে, অ্যাপের নেটওয়ার্ক ট্র্যাফিক যেভাবে প্রভাবিত হবে তা নিচে দেওয়া হলো।

App-Compat ফ্ল্যাগটি বন্ধ করতে নিম্নলিখিত কমান্ডটি ব্যবহার করুন।

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

ত্রুটি

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

ত্রুটির উদাহরণ:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

স্থানীয় নেটওয়ার্ক সংজ্ঞা

এই প্রকল্পে লোকাল নেটওয়ার্ক বলতে এমন একটি আইপি নেটওয়ার্ককে বোঝায় যা ওয়াই-ফাই বা ইথারনেটের মতো ব্রডকাস্ট-সক্ষম নেটওয়ার্ক ইন্টারফেস ব্যবহার করে, কিন্তু সেলুলার (WWAN) বা ভিপিএন সংযোগ অন্তর্ভুক্ত করে না।

নিম্নলিখিতগুলিকে স্থানীয় নেটওয়ার্ক হিসাবে বিবেচনা করা হয়:

IPv4:

• ১৬৯.২৫৪.০.০/১৬ // লিঙ্ক লোকাল
• ১০০.৬৪.০.০/১০ // সিজিএনএটি
• ১০.০.০.০/৮ // আরএফসি১৯১৮
• ১৭২.১৬.০.০/১২ // আরএফসি১৯১৮
• 192.168.0.0/16 // RFC1918

IPv6:

• লিঙ্ক-স্থানীয়
• সরাসরি সংযুক্ত রুট
• থ্রেডের মতো স্টাব নেটওয়ার্ক
• একাধিক সাবনেট (নির্ধারিত হবে)

এছাড়াও, মাল্টিকাস্ট অ্যাড্রেস (224.0.0.0/4, ff00::/8) এবং IPv4 ব্রডকাস্ট অ্যাড্রেস (255.255.255.255) উভয়কেই লোকাল নেটওয়ার্ক অ্যাড্রেস হিসেবে শ্রেণীবদ্ধ করা হয়।

অ্যাপের মালিকানাধীন ছবি