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

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

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

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

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

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

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 会被停用。

如需在 Android 16 中进行测试，请确保您的应用支持无边框设计，并移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 用法，以便您的应用在 Android 15 设备上也能支持无边框设计。如需支持从边缘到边缘的显示，请参阅 Compose 和 Views 指南。

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

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

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

পূর্বাভাসমূলক হোমপেজে ফিরে যাওয়ার অ্যানিমেশন।
পূর্বাভাসমূলক ক্রস-অ্যাক্টিভিটি অ্যানিমেশন।
ভবিষ্যদ্বাণীমূলক ক্রস-টাস্ক অ্যানিমেশন।

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

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，
elegantTextHeight 行为。
以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其
elegantTextHeight 行为。

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

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

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

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

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

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

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

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

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

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

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

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

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

常见的重大更改

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

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

实现细节

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

系统会忽略 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>

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

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

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

অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলির জন্য, BODY_SENSORS পারমিশন android.permissions.health এর অধীনে আরও সূক্ষ্ম পারমিশন ব্যবহার করে, যা হেলথ কানেক্টও ব্যবহার করে। অ্যান্ড্রয়েড ১৬ থেকে, যে কোনো এপিআই যার জন্য আগে BODY_SENSORS বা BODY_SENSORS_BACKGROUND প্রয়োজন ছিল, তার পরিবর্তে সংশ্লিষ্ট android.permissions.health পারমিশন প্রয়োজন হবে। এটি নিম্নলিখিত ডেটা টাইপ, এপিআই এবং ফোরগ্রাউন্ড সার্ভিস টাইপগুলিকে প্রভাবিত করে:

  • Wear OS-এর স্বাস্থ্য পরিষেবা থেকে HEART_RATE_BPM
  • অ্যান্ড্রয়েড সেন্সর ম্যানেজার থেকে 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 এবং অন্যান্য সুনির্দিষ্ট পারমিশন ব্যবহার শুরু করছে, তাদের অবশ্যই অ্যাপটির প্রাইভেসি পলিসি প্রদর্শনের জন্য একটি অ্যাক্টিভিটি ঘোষণা করতে হবে। এটি হেলথ কানেক্ট-এর ক্ষেত্রেও প্রযোজ্য একই আবশ্যকতা।

সংযোগ

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

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

উন্নত বন্ড লস পরিচালনার অংশ হিসাবে, 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 শুনে বন্ডের অবস্থার পরিবর্তনগুলি নিরীক্ষণ করতে পারে।

নিরাপত্তা

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

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

অ্যান্ড্রয়েড 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>

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

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

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

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

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

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

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

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

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