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

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

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

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

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

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>

গুরুত্বপূর্ণ: এই অপ্ট-আউটটি অস্থায়ী এবং ভবিষ্যতের কোনো অ্যান্ড্রয়েড রিলিজে এপিআই লেভেল ৩৭ টার্গেট করার ক্ষেত্রে এটি প্রযোজ্য হবে না। অর্থাৎ, এপিআই লেভেল ৩৭ টার্গেট করা অ্যাপগুলোর জন্য, অন্তত sw600dp ডিসপ্লেতে ওরিয়েন্টেশন, রিসাইজেবিলিটি এবং অ্যাসপেক্ট রেশিও সংক্রান্ত সীমাবদ্ধতাগুলো উপেক্ষা করা হবে।

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

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

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

অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলির জন্য, 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 এর উদ্দেশ্যের বাইরে।

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

“更安全的 intent”功能是一项多阶段安全计划，旨在提高 Android 的 intent 解析机制的安全性。目标是在 intent 处理期间添加检查，并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的侵害。

在 Android 15 中，该功能侧重于发送应用。现在，在 Android 16 中，控制权转移到了接收应用，开发者可以使用其应用清单选择启用严格的 intent 解析。

我们正在实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器匹配：如果 intent 显式定位到某个组件，则应与该组件的 intent 过滤器匹配。

2. 没有操作的 intent 无法匹配任何 intent 过滤器：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

选择启用性质意味着，开发者必须在应用清单中明确启用它，才能使其生效。 因此，此功能的影响将仅限于以下应用：

• 了解“更安全的 intent”功能及其优势。
• 主动选择在应用中采用更严格的 intent 处理实践。

这种选择性采用的方法可最大限度地降低破坏可能依赖于当前不太安全的 intent 解析行为的现有应用的风险。

虽然 Safer Intents 计划在 Android 16 中的初始影响可能有限，但其路线图表明，该计划将在未来的 Android 版本中产生更广泛的影响。我们计划最终将严格的意图解析设为默认行为。

通过使恶意应用更难利用 intent 解析机制中的漏洞，“更安全的 intent”功能有望显著提升 Android 生态系统的安全性。

不过，向选择停用和强制执行的过渡必须谨慎管理，以解决现有应用可能存在的兼容性问题。

实现

开发者需要在应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。以下示例展示了如何为整个应用选择启用该功能，但在接收器上停用/选择停用该功能：

<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> 标记中的属性

有关支持的标志的更多信息：

标志名称	说明
enforceIntentFilter	对传入的 intent 强制执行更严格的匹配
无	针对传入 intent 停用所有特殊匹配规则。指定多个标志时，系统会优先考虑“无”标志，以解决值冲突问题
allowNullAction	放宽匹配规则，以允许匹配没有操作的 intent。此标志应与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

在强制执行处于有效状态时，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息（例如 "Intent does not match component's intent filter:" 和 "Access blocked:"），并带有标记 "PackageManager."。这表示存在可能会影响应用的潜在问题，需要引起注意。

Logcat 过滤条件：

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

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

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 সাফিক্স থাকে) লোকাল নেটওয়ার্ক পারমিশনের প্রয়োজন হবে।

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

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

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

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

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

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

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

দ্রষ্টব্য: অ্যান্ড্রয়েডের ভবিষ্যৎ কোনো সংস্করণে, এই ফিচারটি Nearby devices পারমিশন গ্রুপের একটি নতুন পারমিশন দ্বারা সুরক্ষিত করা হবে।

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

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

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

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) উভয়কেই লোকাল নেটওয়ার্ক অ্যাড্রেস হিসেবে শ্রেণীবদ্ধ করা হয়।

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

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