আচরণগত পরিবর্তন: Android 16 বা এর পরের যেকোনও ভার্সনকে টার্গেট করা অ্যাপ

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

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

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

Android 16 (API লেভেল 36)-এ নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করা হয়েছে, যেগুলি আরও সামঞ্জস্যপূর্ণ, স্বজ্ঞাত ব্যবহারকারীর অভিজ্ঞতা তৈরি করার জন্য উদ্দিষ্ট।

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

Android 15 (API লেভেল ৩৫) টার্গেট করা অ্যাপের জন্য Android 15-এ এজ-টু-এজ এনফোর্স করা হয়েছে, তবে আপনার অ্যাপ R.attr#windowOptOutEdgeToEdgeEnforcement-কে true-এ সেট করে অপ্ট-আউট করতে পারে। Android 16 (API লেভেল ৩৬) টার্গেট করা অ্যাপের জন্য, 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 সংক্রান্ত নির্দেশিকা দেখুন।

আগের ধাপে ফিরে যাওয়া সংক্রান্ত পূর্বাভাসের জন্য মাইগ্রেশন বা অপ্ট-আউট করতে হবে

Android 16 (API লেভেল 36) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করা এবং Android 16 বা তার পরবর্তী যেকোনও ভার্সনের ডিভাইসে চলা অ্যাপের ক্ষেত্রে, আগের ধাপে ফিরে যাওয়া সংক্রান্ত পূর্বাভাসের সিস্টেম অ্যানিমেশন (হোম স্ক্রিনে ফিরে যাওয়া, ক্রস-টাস্ক এবং ক্রস-অ্যাক্টিভিটি) ডিফল্ট হিসেবে চালু করা থাকে। এছাড়াও, onBackPressed-কে আর কল করা হয় না এবং KeyEvent.KEYCODE_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 16 (API লেভেল 36)-এ নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে যা Android সিস্টেমের বিভিন্ন মূল ক্ষমতাকে পরিবর্তন বা প্রসারিত করে।

ফিক্সড রেট ওয়ার্ক শিডিউলিং অপ্টিমাইজেশন

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

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

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

Android 16 (API লেভেল ৩৬) বড় স্ক্রিনের ডিভাইসে অ্যাপ দেখানোর সময় নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে।

অ্যাডাপ্টিভ লেআউট

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

ওরিয়েন্টেশন, রিসাইজ করার সুবিধা ও অ্যাস্পেক্ট রেশিও সংক্রান্ত বিধিনিষেধ উপেক্ষা করুন

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

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

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

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

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

ডিভাইস রোটেট করার অনুমতি দিলে আরও অ্যাক্টিভিটি আবার তৈরি হয়, যার ফলে ব্যবহারকারীর স্টেট সঠিকভাবে সেভ না করা হলে তা হারিয়ে যেতে পারে। UI স্টেট সেভ করুন বিকল্পে গিয়ে UI স্টেট কীভাবে সঠিকভাবে সেভ করবেন তা জানুন।

প্রয়োগ সংক্রান্ত বিবরণ

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

ব্যতিক্রম

Android 16-এর ওরিয়েন্টেশন, রিসাইজ করার সুবিধা ও অ্যাস্পেক্ট রেশিও সংক্রান্ত বিধিনিষেধ নিম্নলিখিত পরিস্থিতিতে প্রযোজ্য হয় না:

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

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

নির্দিষ্ট কোনও অ্যাক্টিভিটি থেকে অপ্ট-আউট করতে, 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 16 (API লেভেল ৩৬)-এ স্বাস্থ্য ও ফিটনেস ডেটা সম্পর্কিত নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করা হয়েছে।

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

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

• Wear OS-এ স্বাস্থ্য পরিষেবা থেকে HEART_RATE_BPM
• Android Sensor Manager থেকে Sensor.TYPE_HEART_RATE
• heartRateAccuracy এবং heartRateBpm, Wear OS-এ ProtoLayout থেকে
• 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 থেকে ডেটা পড়ার অ্যাক্সেসকে সুরক্ষিত করে, এটি স্বাস্থ্য, ফিটনেস ও সুস্থতা সম্পর্কিত ডেটার জন্য Android ডেটাস্টোর।

মোবাইল অ্যাপ

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

কানেক্টিভিটি

Android 16 (API লেভেল 36)-এ ব্লুটুথ স্ট্যাকে নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করা হয়েছে যাতে পেরিফেরাল ডিভাইসের সাথে কানেক্টিভিটি উন্নত করা যায়।

বন্ড লস ও এনক্রিপশন সংক্রান্ত পরিবর্তন ম্যানেজ করার জন্য নতুন ইনটেন্ট

উন্নত বন্ড লস পরিচালনার অংশ হিসাবে, 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 (API লেভেল ৩৬)-এ নিম্নলিখিত নিরাপত্তা সংক্রান্ত পরিবর্তন অন্তর্ভুক্ত আছে।

MediaStore ভার্সন লকডাউন

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

আরও নিরাপদ ইনটেন্ট

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

Android 15-এ ফিচারটি অ্যাপ পাঠানোর উপর ফোকাস করে। এখন Android 16-এর মাধ্যমে, কন্ট্রোল রিসিভিং অ্যাপে শিফট হয়, যা ডেভেলপারদের তাদের অ্যাপ ম্যানিফেস্ট ব্যবহার করে কঠোর ইনটেন্ট রেজোলিউশনে অপ্ট-ইন করার অনুমতি দেয়।

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

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

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

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

প্রভাব

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

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

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

Android 16-এ প্রাথমিক প্রভাব সীমিত হলেও, Safer Intents উদ্যোগের কাছে ভবিষ্যতের Android রিলিজে আরও ব্যাপক প্রভাবের জন্য একটি রোডম্যাপ রয়েছে। পরিকল্পনা হল, শেষ পর্যন্ত কঠোর ইনটেন্ট রেজোলিউশনকে ডিফল্ট অ্যাকশন হিসেবে সেট করা।

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

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

প্রয়োগ

ডেভেলপারদের তাদের অ্যাপ ম্যানিফেস্টে 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:"-এর মতো সতর্কতামূলক লগ মেসেজ ট্রিগার করবে। এটি সম্ভাব্য সমস্যা নির্দেশ করে যা অ্যাপকে প্রভাবিত করতে পারে এবং এতে মনোযোগ দেওয়া প্রয়োজন।

Logcat ফিল্টার:

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

GPU syscall ফিল্টারিং

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

Mali GPU (Pixel 6-9) ব্যবহার করা Pixel ডিভাইসে এই পরিবর্তন করা হয়। Arm তাদের IOCTL-এর অফিসিয়াল ক্যাটেগরি Documentation/ioctl-categories.rst-এ তাদের r54p2 রিলিজ-এ প্রদান করেছে। ভবিষ্যতে ড্রাইভার রিলিজের ক্ষেত্রে এই তালিকা বজায় রাখা হবে।

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

পরীক্ষা করা

আপনি যদি নিম্নলিখিতটির মতো 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. IOCTL তালিকা আপ-টু-ডেট রাখার জন্য কি SoC দায়ী? যেমন, আমার ডিভাইস যদি ARM Mali GPU ব্যবহার করে, তাহলে কি কোনও পরিবর্তনের জন্য আমাকে ARM-এর সাথে যোগাযোগ করতে হবে? ড্রাইভার রিলিজ করার সময় প্রতিটি SoC-কে ডিভাইস অনুযায়ী IOCTL তালিকা আপডেট করতে হবে। যেমন, ড্রাইভার আপডেট করার পরে ARM তাদের প্রকাশিত IOCTL তালিকা আপডেট করবে। তবে, OEM-কে নিশ্চিত করতে হবে যে তারা SEPolicy-তে আপডেট অন্তর্ভুক্ত করেছে এবং প্রয়োজন অনুযায়ী তালিকায় যেকোনও বেছে নেওয়া কাস্টম IOCTL যোগ করেছে।

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

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

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

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

গোপনীয়তা

Android 16 (API লেভেল ৩৬)-এ গোপনীয়তা সংক্রান্ত নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করা হয়েছে।

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

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

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

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

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

প্রভাব

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

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

• লোকাল নেটওয়ার্ক অ্যাড্রেসে র সকেট সরাসরি বা লাইব্রেরি ব্যবহার (যেমন, mDNS বা SSDP পরিষেবা ডিসকভারি প্রোটোকল)
• লোকাল নেটওয়ার্ক অ্যাক্সেস করে এমন ফ্রেমওয়ার্ক লেভেল ক্লাসের ব্যবহার (যেমন, NsdManager)

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

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

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

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

ডেভেলপার নির্দেশিকা (চালু করা)

লোকাল নেটওয়ার্ক সংক্রান্ত বিধিনিষেধ চালু করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

1. 25Q2 বিটা ৩ বা তার পরবর্তী যেকোনও ভার্সন সহ বিল্ডে ডিভাইস ফ্ল্যাশ করুন।
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. সেটিংস > অ্যাপ > [Application Name] > অনুমতি > আশেপাশের ডিভাইস > অনুমতি দিন বিকল্পে যান।

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

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

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

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

সমস্যা

এইসব বিধিনিষেধের কারণে হওয়া সমস্যা কলিং সকেটে ফেরত পাঠানো হবে যখনই এটি লোকাল নেটওয়ার্ক অ্যাড্রেসে সেন্ড বা সেন্ড ভ্যারিয়েন্ট ইনভোক করে।

সমস্যার উদাহরণ:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

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

এই প্রোজেক্টে লোকাল নেটওয়ার্ক বলতে এমন একটি IP নেটওয়ার্ককে বোঝায় যা ব্রডকাস্ট-সক্ষম নেটওয়ার্ক ইন্টারফেস ব্যবহার করে, যেমন ওয়াই-ফাই বা ইথারনেট, তবে সেলুলার (WWAN) বা VPN কানেকশন বাদ দেয়।

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

IPv4:

• 169.254.0.0/16 // লিঙ্ক লোকাল
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

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

এছাড়াও, মাল্টিকাস্ট অ্যাড্রেস (২২৪.০.০.০/৪, ff০০::/৮) এবং IPv৪ ব্রডকাস্ট অ্যাড্রেস (২৫৫.২৫৫.২৫৫.২৫৫) দুটিই স্থানীয় নেটওয়ার্ক অ্যাড্রেস হিসেবে শ্রেণীবদ্ধ করা হয়।

অ্যাপের মালিকানাধীন ফটো