আচরণগত পরিবর্তন: 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 或更高版本的设备上运行的应用，系统会默认启用预测性返回系统动画（返回主屏幕、跨任务和跨 activity）。此外，系统不会调用 onBackPressed，也不会再分派 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，而您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false，以暂时停用预测性返回。

预测性返回主屏幕动画。

预测性跨 activity 动画。

预测性跨任务动画。

এলিগ্যান্ট ফন্ট API বন্ধ ও বাতিল করা হয়েছে

以 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 (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 রিলিজের সময় API লেভেল ৩৭ টার্গেট করার ক্ষেত্রে এটি প্রযোজ্য হবে না। অর্থাৎ, API লেভেল ৩৭ টার্গেট করা অ্যাপের ক্ষেত্রে, কমপক্ষে sw600dp ডিসপ্লেতে ওরিয়েন্টেশন, রিসাইজ করার সুবিধা এবং অ্যাস্পেক্ট রেশিও সংক্রান্ত বিধিনিষেধ উপেক্ষা করা হয়।

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

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 个新 intent，以便应用更好地了解键值对丢失和加密更改。

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

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

适应不同的 OEM 实现

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

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

• 如果广播 ACTION_KEY_MISSING intent：

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

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

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

• 如果未广播 ACTION_KEY_MISSING intent：

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

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

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

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

নিরাপত্তা

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

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

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

影响

由于该功能具有选择启用性质，因此开发者必须在其应用清单中明确启用该功能，它才能生效。 因此，该功能的影响范围仅限于满足以下条件的应用：

• 了解 Safer Intents 功能及其优势。
• 主动选择在应用中采用更严格的 intent 处理做法。

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

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

Safer Intents 功能可以提高恶意应用利用 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 的所有特殊匹配规则。指定多个标志时，如果值存在冲突，则优先采用“none”标志
allowNullAction	放宽匹配规则，允许不含操作的 intent 进行匹配。此标志将与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

强制执行生效后，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息，例如带有 "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 ব্যবহার করার প্রয়োজন হলে, একটি বাগ ফাইল করুন এবং এটি [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 ইন-মার্কেট ডিভাইসের ক্ষেত্রে এই পরিবর্তন প্রযোজ্য (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)

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

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

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

মনে রাখবেন: স্থানীয় নেটওয়ার্ক অ্যাক্সেস প্রয়োজন এমন Android Webviews থেকে আসা ট্রাফিক হোস্ট অ্যাপ থেকে অনুমতির স্ট্যাটাস ইনহেরিট করবে

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

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

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

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

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

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] > অনুমতি > আশেপাশের ডিভাইস > অনুমতি দিন বিকল্পে যান।

মনে রাখবেন: ভবিষ্যতে Android রিলিজের ক্ষেত্রে, এই ফিচারটি আশেপাশের ডিভাইসের অনুমতি গ্রুপে নতুন অনুমতির মাধ্যমে সুরক্ষিত করা হবে

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

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

অনুমতি	আউটবাউন্ড LAN অনুরোধ	আউটবাউন্ড/ইনবাউন্ড ইন্টারনেট অনুরোধ	ইনবাউন্ড LAN অনুরোধ
অনুমোদন করা হয়েছে	Works	Works	Works
অনুমতি দেওয়া হয়নি	ব্যর্থ	Works	ব্যর্থ

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

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৪ ব্রডকাস্ট অ্যাড্রেস (২৫৫.২৫৫.২৫৫.২৫৫) দুটিই স্থানীয় নেটওয়ার্ক অ্যাড্রেস হিসেবে শ্রেণীবদ্ধ করা হয়।

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

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