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

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

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

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

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

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

Android 15 (API লেভেল 35) টার্গেট করা অ্যাপগুলির জন্য Android 15 এজ-টু-এজ প্রয়োগ করেছে , কিন্তু আপনার অ্যাপ R.attr#windowOptOutEdgeToEdgeEnforcement true এ সেট করে অপ্ট-আউট করতে পারে। Android 16 (API লেভেল 36) টার্গেট করা অ্যাপগুলির জন্য, R.attr#windowOptOutEdgeToEdgeEnforcement কে অবচিত এবং অক্ষম করা হয়েছে, এবং আপনার অ্যাপ এজ-টু-এজ যাওয়ার অপ্ট-আউট করতে পারবে না।

• যদি আপনার অ্যাপটি Android 16 (API লেভেল 36) কে টার্গেট করে এবং একটি Android 15 ডিভাইসে চলে, তাহলে R.attr#windowOptOutEdgeToEdgeEnforcement কাজ করতে থাকবে।
• যদি আপনার অ্যাপটি Android 16 (API লেভেল 36) কে টার্গেট করে এবং একটি Android 16 ডিভাইসে চলে, R.attr#windowOptOutEdgeToEdgeEnforcement অক্ষম থাকে।

অ্যান্ড্রয়েড ১৬-তে পরীক্ষার জন্য, নিশ্চিত করুন যে আপনার অ্যাপটি এজ-টু-এজ সমর্থন করে এবং R.attr#windowOptOutEdgeToEdgeEnforcement এর যেকোনো ব্যবহার সরিয়ে ফেলুন যাতে আপনার অ্যাপটি অ্যান্ড্রয়েড ১৫ ডিভাইসে এজ-টু-এজ সমর্থন করে। এজ-টু-এজ সমর্থন করতে, কম্পোজ এবং ভিউ নির্দেশিকা দেখুন।

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

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

যদি আপনার অ্যাপটি back ইভেন্টটি আটকে দেয় এবং আপনি এখনও predictivate back এ মাইগ্রেট না করে থাকেন, তাহলে সমর্থিত 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 টার্গেট করার আগে, যখন scheduleAtFixedRate একটি বৈধ প্রক্রিয়া লাইফসাইকেলের বাইরে থাকার কারণে একটি টাস্ক এক্সিকিউশন মিস করে, অ্যাপটি একটি বৈধ লাইফসাইকেলে ফিরে গেলে সমস্ত মিস করা এক্সিকিউশন অবিলম্বে কার্যকর হয়।

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

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

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

অভিযোজিত লেআউট

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

ওরিয়েন্টেশন, আকার পরিবর্তনযোগ্যতা এবং আকৃতির অনুপাতের সীমাবদ্ধতা উপেক্ষা করুন

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

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

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

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

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

ডিভাইস ঘূর্ণনের অনুমতি দিলে আরও বেশি অ্যাক্টিভিটি পুনঃসৃষ্টি হয়, যা সঠিকভাবে সংরক্ষণ না করলে ব্যবহারকারীর অবস্থা হারাতে পারে। Save UI states- এ 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 ওরিয়েন্টেশন, আকার পরিবর্তনযোগ্যতা এবং আকৃতির অনুপাতের সীমাবদ্ধতা প্রযোজ্য নয়:

• গেমস ( 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>

স্বাস্থ্য এবং ফিটনেস

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

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

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Health Services on Wear OS
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

সংযোগ

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

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

উন্নত বন্ড লস পরিচালনার অংশ হিসাবে, 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-এর আচরণের মতো।

  এই পরিস্থিতিতে, বন্ড লস ইভেন্টগুলি সনাক্ত করতে এবং পরিচালনা করতে আপনার অ্যাপটিকে আগের অ্যান্ড্রয়েড রিলিজের মতো তার বিদ্যমান বন্ড লস হ্যান্ডলিং মেকানিজম চালিয়ে যেতে হবে।

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

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

নিরাপত্তা

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

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

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

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

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

<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>

More on the supported flags:

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

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

জিপিইউ সিস্টেমকল ফিল্টারিং

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

এই পরিবর্তনটি মালি জিপিইউ (পিক্সেল ৬-৯) ব্যবহার করে পিক্সেল ডিভাইসগুলিতে ঘটে। আর্ম তাদের r54p2 রিলিজের প্রথম Documentation/ioctl-categories.rst এ তাদের IOCTL-এর অফিসিয়াল শ্রেণীবিভাগ প্রদান করেছে। ভবিষ্যতের ড্রাইভার রিলিজে এই তালিকা বজায় রাখা হবে।

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

পরীক্ষামূলক

যদি আপনি নিম্নলিখিতগুলির মতো একটি 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 6-9) ব্যবহার করে সমস্ত Pixel ইন-মার্কেট ডিভাইসের ক্ষেত্রে প্রযোজ্য। এই পরিবর্তনটি প্রয়োগ করার জন্য কোনও ব্যবহারকারীর পদক্ষেপের প্রয়োজন নেই।

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

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

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

গোপনীয়তা

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

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

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

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

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

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

প্রভাব

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

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

• স্থানীয় নেটওয়ার্ক ঠিকানায় কাঁচা সকেটের সরাসরি বা লাইব্রেরি ব্যবহার (যেমন mDNS বা SSDP পরিষেবা আবিষ্কার প্রোটোকল)
• স্থানীয় নেটওয়ার্ক অ্যাক্সেস করে এমন ফ্রেমওয়ার্ক স্তরের ক্লাসের ব্যবহার (যেমন NsdManager)

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

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

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

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

ডেভেলপার নির্দেশিকা (অপ্ট-ইন)

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

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

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

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

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

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

ত্রুটি

এই বিধিনিষেধ থেকে উদ্ভূত ত্রুটিগুলি কলিং সকেটে ফেরত পাঠানো হবে যখনই এটি স্থানীয় নেটওয়ার্ক ঠিকানায় একটি প্রেরণ বা প্রেরণ বৈকল্পিক আহ্বান করবে।

উদাহরণ ত্রুটি:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

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

এই প্রকল্পে একটি স্থানীয় নেটওয়ার্ক বলতে এমন একটি আইপি নেটওয়ার্ককে বোঝায় যা ওয়াই-ফাই বা ইথারনেটের মতো একটি সম্প্রচার-সক্ষম নেটওয়ার্ক ইন্টারফেস ব্যবহার করে, কিন্তু সেলুলার (WWAN) বা VPN সংযোগ বাদ দেয়।

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

আইপিভি৪:

• ১৬৯.২৫৪.০.০/১৬ // স্থানীয় লিঙ্ক
• ১০০.৬৪.০.০/১০ // সিজিএনএটি
• ১০.০.০.০/৮ // আরএফসি১৯১৮
• ১৭২.১৬.০.০/১২ // আরএফসি১৯১৮
• ১৯২.১৬৮.০.০/১৬ // আরএফসি১৯১৮

আইপিভি৬:

• লিংক-স্থানীয়
• সরাসরি সংযুক্ত রুট
• থ্রেডের মতো স্টাব নেটওয়ার্ক
• মাল্টিপল-সাবনেট (টিবিডি)

অতিরিক্তভাবে, মাল্টিকাস্ট ঠিকানা (224.0.0.0/4, ff00::/8) এবং IPv4 সম্প্রচার ঠিকানা (255.255.255.255) উভয়কেই স্থানীয় নেটওয়ার্ক ঠিকানা হিসাবে শ্রেণীবদ্ধ করা হয়েছে।

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