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

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

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

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

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

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

Android 15 (API লেভেল 35) টার্গেট করা অ্যাপগুলির জন্য Android 15 এজ-টু-এজ প্রয়োগ করেছে , কিন্তু আপনার অ্যাপ R.attr#windowOptOutEdgeToEdgeEnforcement true এ সেট করে অপ্ট-আউট করতে পারে। Android 16 (API লেভেল 36) টার্গেট করা অ্যাপগুলির জন্য, R.attr#windowOptOutEdgeToEdgeEnforcement কে অবচিত এবং অক্ষম করা হয়েছে, এবং আপনার অ্যাপ এজ-টু-এজ যাওয়ার অপ্ট-আউট করতে পারবে না।

• যদি আপনার অ্যাপটি Android 16 (API লেভেল 36) কে টার্গেট করে এবং একটি Android 15 ডিভাইসে চলে, তাহলে R.attr#windowOptOutEdgeToEdgeEnforcement কাজ করতে থাকবে।
• যদি আপনার অ্যাপটি Android 16 (API লেভেল 36) কে টার্গেট করে এবং একটি Android 16 ডিভাইসে চলে, R.attr#windowOptOutEdgeToEdgeEnforcement অক্ষম থাকে।

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

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

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

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

ভবিষ্যদ্বাণীমূলক ব্যাক-টু-হোম অ্যানিমেশন।

ভবিষ্যদ্বাণীমূলক ক্রস-অ্যাক্টিভিটি অ্যানিমেশন।

ভবিষ্যদ্বাণীমূলক ক্রস-টাস্ক অ্যানিমেশন।

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

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

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

Android 14 (API লেভেল 34) এবং তার নিচের অ্যাপ্লিকেশানগুলির জন্য elegantTextHeight আচরণ বা Android 15 (API লেভেল 35) টার্গেট করা অ্যাপ্লিকেশানগুলির জন্য যা elegantTextHeight অ্যাট্রিবিউটকে false সেট করে ডিফল্টকে ওভাররড করে৷

Android 16 (API লেভেল 36) টার্গেট করা অ্যাপগুলির জন্য elegantTextHeight আচরণ, অথবা Android 15 (API লেভেল 35) টার্গেট করা অ্যাপগুলির জন্য যা elegantTextHeight অ্যাট্রিবিউটকে false সেট করে ডিফল্ট ওভাররাইড করেনি।

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

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

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

在以 Android 16 为目标平台之前，如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行，则当应用返回到有效的生命周期时，所有错过的执行会立即执行。

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 兼容性标志进行测试。

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

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

অভিযোজিত লেআউট

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备方向如何。在当今多设备的世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，屏幕方向、尺寸可调整性和宽高比限制不再适用于最小宽度 >= 600dp 的显示屏。无论宽高比或用户偏好的屏幕方向如何，应用都会填满整个显示窗口，且不会采用竖条模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素，例如布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 API 会被大屏设备忽略：

• 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 16（API 级别 36）为目标平台的应用，默认情况下，大屏设备会忽略应用的屏幕方向、可调整尺寸性和宽高比限制，但尚未完全准备就绪的每个应用都可以选择停用此行为，从而暂时替换此行为（这会导致应用恢复到之前放置在兼容模式下的行为）。

异常

在以下情况下，Android 16 的屏幕方向、尺寸调整能力和宽高比限制不适用：

• 游戏（基于 android:appCategory 标志）
• 用户在设备的宽高比设置中明确选择启用应用的默认行为
• 小于 sw600dp 的屏幕

暂时停用

如需选择停用特定 activity，请声明 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 清单属性：

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

如果您的应用有太多部分尚未准备好支持 Android 16，您可以在应用级别应用相同的属性，从而完全选择不启用该功能：

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

重要提示： 此选择停用是临时性的，在未来的 Android 版本中以 API 级别 37 为目标平台时，此选择停用将不再适用。也就是说，对于以 API 级别 37 为目标的应用，在至少为 sw600dp 的显示屏上，系统会忽略屏幕方向、尺寸可调整性和宽高比限制。

স্বাস্থ্য এবং ফিটনেস

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

স্বাস্থ্য এবং ফিটনেসের অনুমতি

Android 16 (API লেভেল 36) বা তার বেশি ভার্সনের অ্যাপগুলির জন্য, BODY_SENSORS অনুমতিগুলি android.permissions.health এর অধীনে আরও গ্রানুলার অনুমতি ব্যবহার করে, যা Health Connect ও ব্যবহার করে। Android 16 অনুসারে, পূর্বে BODY_SENSORS বা BODY_SENSORS_BACKGROUND প্রয়োজন এমন যেকোনো API-এর জন্য সংশ্লিষ্ট android.permissions.health অনুমতি প্রয়োজন। এটি নিম্নলিখিত ডেটা টাইপ, API এবং ফোরগ্রাউন্ড পরিষেবা টাইপগুলিকে প্রভাবিত করে:

• Wear OS-এ Health Services থেকে HEART_RATE_BPM
• Android সেন্সর ম্যানেজার থেকে Sensor.TYPE_HEART_RATE
• Wear OS-এ ProtoLayout থেকে heartRateAccuracy এবং heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH যেখানে BODY_SENSORS এর পরিবর্তে সংশ্লিষ্ট android.permission.health অনুমতি প্রয়োজন

যদি আপনার অ্যাপ এই API গুলি ব্যবহার করে, তাহলে এটি সংশ্লিষ্ট গ্রানুলার অনুমতিগুলির জন্য অনুরোধ করবে:

• ব্যবহারের সময় হার্ট রেট, SpO2, অথবা ত্বকের তাপমাত্রা পর্যবেক্ষণের জন্য: android.permissions.health এর অধীনে BODY_SENSORS এর পরিবর্তে READ_HEART_RATE মতো গ্রানুলার অনুমতির অনুরোধ করুন।
• ব্যাকগ্রাউন্ড সেন্সর অ্যাক্সেসের জন্য: BODY_SENSORS_BACKGROUND এর পরিবর্তে READ_HEALTH_DATA_IN_BACKGROUND অনুরোধ করুন।

এই অনুমতিগুলি স্বাস্থ্য, ফিটনেস এবং সুস্থতার ডেটার জন্য অ্যান্ড্রয়েড ডেটাস্টোর, Health Connect থেকে পড়ার ডেটাতে অ্যাক্সেস রক্ষা করার অনুমতিগুলির মতোই।

মোবাইল অ্যাপস

READ_HEART_RATE এবং অন্যান্য গ্রানুলার অনুমতি ব্যবহার করতে মাইগ্রেট করা মোবাইল অ্যাপগুলিকে অ্যাপের গোপনীয়তা নীতি প্রদর্শনের জন্য একটি কার্যকলাপ ঘোষণা করতে হবে। এটি Health Connect এর মতোই প্রয়োজন।

গুরুত্বপূর্ণ: মোবাইল অ্যাপের যুক্তি প্রদানে ব্যর্থ হলে অনুমতি বাতিল করা হবে।

সংযোগ

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

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

উন্নত বন্ড লস পরিচালনার অংশ হিসাবে, Android 16 বন্ড ক্ষয় এবং এনক্রিপশন পরিবর্তন সম্পর্কে আরও বেশি সচেতনতা সহ অ্যাপগুলি সরবরাহ করার জন্য 2টি নতুন উদ্দেশ্যও প্রবর্তন করেছে।

Android 16 টার্গেট করা অ্যাপগুলি এখন করতে পারে:

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

বিভিন্ন OEM বাস্তবায়নের সাথে মানিয়ে নেওয়া

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

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

• যদি ACTION_KEY_MISSING অভিপ্রায় সম্প্রচার করা হয়:

  ACL (অ্যাসিনক্রোনাস সংযোগ-কম) লিঙ্কটি সিস্টেম দ্বারা সংযোগ বিচ্ছিন্ন করা হবে, কিন্তু ডিভাইসের জন্য বন্ড তথ্য (যেমন এখানে বর্ণনা করা হয়েছে) ধরে রাখা হবে।

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

  ACTION_KEY_MISSING প্রাপ্তির পরে যদি একটি ডিভাইস সংযোগ বিচ্ছিন্ন হয়ে যায়, আপনার অ্যাপটিকে পুনরায় সংযোগ করার বিষয়ে সতর্ক হওয়া উচিত, কারণ ডিভাইসটি আর সিস্টেমের সাথে বন্ধন নাও থাকতে পারে৷

• যদি ACTION_KEY_MISSING অভিপ্রায় সম্প্রচার না করা হয়:

  ACL লিঙ্কটি সংযুক্ত থাকবে এবং ডিভাইসের বন্ড তথ্য সিস্টেম দ্বারা সরিয়ে দেওয়া হবে, Android 15-এর আচরণের মতো।

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

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

Android 16 টার্গেট করা সমস্ত অ্যাপ এখন CompanionDeviceManager এ একটি পাবলিক API ব্যবহার করে ব্লুটুথ ডিভাইসগুলিকে আনপেয়ার করতে সক্ষম৷ যদি একটি সহচর ডিভাইস একটি CDM অ্যাসোসিয়েশন হিসাবে পরিচালিত হয়, তাহলে অ্যাপটি সংশ্লিষ্ট ডিভাইসে নতুন removeBond(int) API ব্যবহার করে ব্লুটুথ বন্ড অপসারণ ট্রিগার করতে পারে। অ্যাপটি ব্লুটুথ ডিভাইসের সম্প্রচার ইভেন্ট ACTION_BOND_STATE_CHANGED শুনে বন্ডের অবস্থার পরিবর্তনগুলি নিরীক্ষণ করতে পারে।

নিরাপত্তা

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

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

对于以 Android 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>

দ্রষ্টব্য: অ্যাট্রিবিউটটি <application> ট্যাগের পাশাপাশি <activity> , <activity-alias> , <receiver> , <service> , <provider> এর মতো কম্পোনেন্ট ট্যাগেও নির্দিষ্ট করা যেতে পারে এবং কম্পোনেন্টের অ্যাট্রিবিউটটি <application> ট্যাগে থাকা জিনিসগুলিকে ওভাররাইড করতে ব্যবহার করা যেতে পারে।

সমর্থিত পতাকা সম্পর্কে আরও জানুন:

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

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

যখন এনফোর্সমেন্ট সক্রিয় থাকে, তখন যদি ইনটেন্ট কলার সঠিকভাবে ইনটেন্ট পূরণ করে থাকে তাহলে অ্যাপগুলি সঠিকভাবে কাজ করবে। তবে, ব্লক করা ইনটেন্টগুলি "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:")

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

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

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

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

পরীক্ষামূলক

যদি আপনি নিম্নলিখিতগুলির মতো একটি 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 ব্যবহার করতে হয়, তাহলে অনুগ্রহ করে একটি বাগ ফাইল করুন এবং এটি [e-mail] ঠিকানায় বরাদ্দ করুন।

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

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

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

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

4. এই পরিবর্তন কি সমস্ত Pixel ইন-মার্কেট ডিভাইসের ক্ষেত্রে স্বয়ংক্রিয়ভাবে প্রযোজ্য, নাকি এই পরিবর্তনটি প্রয়োগ করার জন্য ব্যবহারকারীর কোনও পদক্ষেপের প্রয়োজন? এই পরিবর্তনটি Mali GPU (Pixel 6-9) ব্যবহার করে সমস্ত Pixel ইন-মার্কেট ডিভাইসের ক্ষেত্রে প্রযোজ্য। এই পরিবর্তনটি প্রয়োগ করার জন্য কোনও ব্যবহারকারীর পদক্ষেপের প্রয়োজন নেই।

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

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

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

গোপনীয়তা

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

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

INTERNET অনুমতিপ্রাপ্ত যেকোনো অ্যাপ ল্যানের ডিভাইসগুলিতে অ্যাক্সেস করতে পারে। এটি অ্যাপগুলিকে স্থানীয় ডিভাইসের সাথে সংযোগ করা সহজ করে তোলে তবে এর গোপনীয়তার প্রভাবও রয়েছে যেমন ব্যবহারকারীর আঙুলের ছাপ তৈরি করা এবং অবস্থানের জন্য প্রক্সি হওয়া।

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

রিলিজ পরিকল্পনা

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

প্রভাব

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

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

• স্থানীয় নেটওয়ার্ক ঠিকানায় কাঁচা সকেটের সরাসরি বা লাইব্রেরি ব্যবহার (যেমন mDNS বা SSDP পরিষেবা আবিষ্কার প্রোটোকল)
• স্থানীয় নেটওয়ার্ক অ্যাক্সেস করে এমন ফ্রেমওয়ার্ক স্তরের ক্লাসের ব্যবহার (যেমন NsdManager)

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

অ্যাপ লো লেভেল নেটওয়ার্ক অপারেশন	স্থানীয় নেটওয়ার্কের অনুমতি প্রয়োজন
একটি বহির্গামী TCP সংযোগ তৈরি করা হচ্ছে	হ্যাঁ
আগত TCP সংযোগ গ্রহণ করা হচ্ছে	হ্যাঁ
একটি UDP ইউনিকাস্ট, মাল্টিকাস্ট, সম্প্রচার পাঠানো হচ্ছে	হ্যাঁ
একটি আগত UDP ইউনিকাস্ট, মাল্টিকাস্ট, সম্প্রচার গ্রহণ করা হচ্ছে	হ্যাঁ

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

দ্রষ্টব্য: স্থানীয় নেটওয়ার্ক অ্যাক্সেসের প্রয়োজন এমন অ্যান্ড্রয়েড ওয়েবভিউ থেকে আসা ট্র্যাফিক হোস্ট অ্যাপ থেকে অনুমতির অবস্থা উত্তরাধিকার সূত্রে পাবে।

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

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

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

ডেভেলপার নির্দেশিকা (অপ্ট-ইন)

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

1. ডিভাইসটিকে 25Q2 বিটা 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. সেটিংস > অ্যাপস > [অ্যাপ্লিকেশনের নাম] > অনুমতি > কাছাকাছি ডিভাইস > অনুমতি দিন -এ যান।

দ্রষ্টব্য: ভবিষ্যতের অ্যান্ড্রয়েড রিলিজে, এই বৈশিষ্ট্যটি কাছাকাছি ডিভাইসের অনুমতি গোষ্ঠীতে একটি নতুন অনুমতি দ্বারা সুরক্ষিত থাকবে।

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

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

অনুমতি	আউটবাউন্ড ল্যান অনুরোধ	আউটবাউন্ড/ইনবাউন্ড ইন্টারনেট অনুরোধ	ইনবাউন্ড ল্যান অনুরোধ
মঞ্জুর	কাজ	কাজ	কাজ
অনুমোদিত নয়	ব্যর্থতা	কাজ	ব্যর্থতা

অ্যাপ-কম্প্যাট ফ্ল্যাগটি টগল-অফ করতে নিম্নলিখিত কমান্ডটি ব্যবহার করুন

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

ত্রুটি

এই বিধিনিষেধ থেকে উদ্ভূত ত্রুটিগুলি কলিং সকেটে ফেরত পাঠানো হবে যখনই এটি স্থানীয় নেটওয়ার্ক ঠিকানায় একটি প্রেরণ বা প্রেরণ বৈকল্পিক আহ্বান করবে।

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

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

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

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

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

আইপিভি৪:

• ১৬৯.২৫৪.০.০/১৬ // স্থানীয় লিঙ্ক
• ১০০.৬৪.০.০/১০ // সিজিএনএটি
• ১০.০.০.০/৮ // আরএফসি১৯১৮
• ১৭২.১৬.০.০/১২ // আরএফসি১৯১৮
• ১৯২.১৬৮.০.০/১৬ // আরএফসি১৯১৮

আইপিভি৬:

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

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

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

{% অন্তর্ভুক্ত "/training/data-storage/shared/___owned-photos" %}