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

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

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

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

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

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

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

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

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

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

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

অ্যান্ড্রয়েড ১৫- তে, পাঠানোর অ্যাপের উপর দৃষ্টি নিবদ্ধ করা বৈশিষ্ট্যটি এখন অ্যান্ড্রয়েড ১৬-তে, গ্রহণকারী অ্যাপের উপর নিয়ন্ত্রণ স্থানান্তরিত করে, যার ফলে ডেভেলপাররা তাদের অ্যাপ ম্যানিফেস্ট ব্যবহার করে কঠোর অভিপ্রায় সমাধানে অপ্ট-ইন করতে পারেন।

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

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

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

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

প্রভাব

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

• নিরাপদ উদ্দেশ্য বৈশিষ্ট্য এবং এর সুবিধা সম্পর্কে সচেতন।
• তাদের অ্যাপগুলিতে কঠোর অভিপ্রায় পরিচালনার অনুশীলনগুলি সক্রিয়ভাবে অন্তর্ভুক্ত করার সিদ্ধান্ত নিন।

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

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

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

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

বাস্তবায়ন

ডেভেলপারদের তাদের অ্যাপ ম্যানিফেস্টে 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>

সমর্থিত পতাকা সম্পর্কে আরও জানুন:

পরীক্ষা এবং ডিবাগিং

যখন এনফোর্সমেন্ট সক্রিয় থাকে, তখন যদি ইনটেন্ট কলার সঠিকভাবে ইনটেন্ট পূরণ করে থাকে তাহলে অ্যাপগুলি সঠিকভাবে কাজ করবে। তবে, ব্লক করা ইনটেন্টগুলি "Intent does not match component's intent filter:" এবং "Access blocked:" এর মতো সতর্কতা লগ বার্তাগুলি ট্রিগার করবে যার সাথে "PackageManager." এটি এমন একটি সম্ভাব্য সমস্যা নির্দেশ করে যা অ্যাপটিকে প্রভাবিত করতে পারে এবং মনোযোগ দেওয়ার প্রয়োজন।

লগক্যাট ফিল্টার:

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

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

To harden the Mali GPU surface, Mali GPU IOCTLs that have been deprecated or are intended solely for GPU development have been blocked in production builds. Additionally, IOCTLs used for GPU profiling have been restricted to the shell process or debuggable applications. Refer to the SAC update for more details on the platform-level policy.

This change takes place on Pixel devices using the Mali GPU (Pixel 6-9). Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases.

This change does not impact supported graphics APIs (including Vulkan and OpenGL), and is not expected to impact developers or existing applications. GPU profiling tools such as the Streamline Performance Analyzer and the Android GPU Inspector won't be affected.

Testing

If you see a SELinux denial similar to the following, it is likely your application has been impacted by this change:

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

If your application needs to use blocked IOCTLs, please file a bug and assign it to android-partner-security@google.com.

FAQ

1. Does this policy change apply to all OEMs? This change will be opt-in, but available to any OEMs who would like to use this hardening method. Instructions for implementing the change can be found in the implementation documentation.

2. Is it mandatory to make changes in the OEM codebase to implement this, or does it come with a new AOSP release by default? The platform-level change will come with a new AOSP release by default. Vendors may opt-in to this change in their codebase if they would like to apply it.

3. Are SoCs responsible for keeping the IOCTL list up to date? For example, if my device uses an ARM Mali GPU, would I need to reach out to ARM for any of the changes? Individual SoCs must update their IOCTL lists per device upon driver release. For example, ARM will update their published IOCTL list upon driver updates. However, OEMs should make sure that they incorporate the updates in their SEPolicy, and add any selected custom IOCTLs to the lists as needed.

4. Does this change apply to all Pixel in-market devices automatically, or is a user action required to toggle something to apply this change? This change applies to all Pixel in-market devices using the Mali GPU (Pixel 6-9). No user action is required to apply this change.

5. Will use of this policy impact the performance of the kernel driver? This policy was tested on the Mali GPU using GFXBench, and no measurable change to GPU performance was observed.

6. Is it necessary for the IOCTL list to align with the current userspace and kernel driver versions? Yes, the list of allowed IOCTLs must be synchronized with the IOCTLs supported by both the userspace and kernel drivers. If the IOCTLs in the user space or kernel driver are updated, the SEPolicy IOCTL list must be updated to match.

7. ARM has categorized IOCTLs as 'restricted' / 'instrumentation', but we want to use some of them in production use-cases, and/or deny others. Individual OEMs/SoCs are responsible for deciding on how to categorize the IOCTLs they use, based on the configuration of their userspace Mali libraries. ARM's list can be used to help decide on these, but each OEM/SoC's use-case may be different.

গোপনীয়তা

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

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

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

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

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