আচরণগত পরিবর্তন: 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 সংক্রান্ত নির্দেশিকা দেখুন।

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

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs, or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

The predictive back-to-home animation.

The predictive cross-activity animation.

The predictive cross-task animation.

এলিগ্যান্ট ফন্ট 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 সিস্টেমের বিভিন্ন মূল ক্ষমতাকে পরিবর্তন বা প্রসারিত করে।

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

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

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

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 ভার্সন লকডাউন

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

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

কাজ করে এমন ফ্ল্যাগ সম্পর্কে আরও তথ্য:

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

টেস্টিং ও ডিবাগিং

এনফোর্সমেন্ট অ্যাক্টিভ থাকলে, ইনটেন্ট কলার সঠিকভাবে ইনটেন্ট পপুলেট করলে, অ্যাপ সঠিকভাবে কাজ করবে। তবে, ব্লক করা ইনটেন্ট "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 WebView 的流量将继承宿主应用的权限状态

上述规则的例外情况：

• 如果设备的 DNS 服务器位于本地网络中，则进出该服务器（通过端口 53）的流量不需要本地网络访问权限。
• 使用输出切换器作为应用内选择器的应用不需要本地网络权限（更多指南将于 2025 年第 4 季度发布）。

注意： 许多媒体投放场景都依赖于对本地网络的访问，并且会受到此项变更的影响。不过，并非所有提供投屏功能的应用都需要请求这项新权限。25Q4 中将提供用于处理投屏场景的未来 API 和指南。

开发者指南（选择启用）

如需选择启用本地网络限制，请执行以下操作：

1. 将设备刷写到搭载 25Q2 Beta 3 或更高版本的 build。
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. 依次前往设置 > 应用 > [应用名称] > 权限 > 附近的设备 > 允许。

注意： 在未来的 Android 版本中，此功能将由“附近的设备”权限组中的新权限进行保护

现在，您的应用对本地网络的访问权限应该已恢复，并且所有场景都应该像选择启用该应用之前一样正常运行。

本地网络保护强制执行后，应用网络流量将受到以下影响。

权限	出站 LAN 请求	出站/入站互联网请求	入站 LAN 请求
已授予	Works	Works	Works
未授予	最差排行榜	Works	最差排行榜

使用以下命令关闭应用兼容性标志

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

错误

每当调用套接字调用 send 或 send 变体到本地网络地址时，这些限制引起的错误都会返回给调用套接字。

错误示例：

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

本地网络定义

此项目中的本地网络是指利用支持广播的网络接口（例如 Wi-Fi 或以太网）的 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：

• 链路本地
• 直接连接的路由
• 桩网络（例如 Thread）
• 多个子网（待定）

此外，多播地址（224.0.0.0/4、ff00::/8）和 IPv4 广播地址 (255.255.255.255) 也被归类为本地网络地址。

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

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.