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

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

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

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

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

এজ টু এজ অপ্ট-আউট চলে যাচ্ছে

অ্যান্ড্রয়েড 15 (API লেভেল 35) টার্গেট করা অ্যাপ্লিকেশানগুলির জন্য এজ-টু-এজ এনফোর্স করেছে , কিন্তু আপনার অ্যাপটি 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 অক্ষম করা হয়েছে।

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

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

Android 16 (API স্তর 36) বা উচ্চতর এবং Android 16 বা উচ্চতর ডিভাইসে চলমান অ্যাপ্লিকেশানগুলির জন্য, পূর্বাভাসমূলক ব্যাক সিস্টেম অ্যানিমেশনগুলি (ব্যাক-টু-হোম, ক্রস-টাস্ক, এবং ক্রস-অ্যাক্টিভিটি) ডিফল্টরূপে সক্রিয় থাকে। উপরন্তু, onBackPressed বলা হয় না এবং KeyEvent.KEYCODE_BACK আর পাঠানো হয় না।

যদি আপনার অ্যাপ ব্যাক ইভেন্টে বাধা দেয় এবং আপনি এখনও পূর্বাভাসমূলক ব্যাক এ মাইগ্রেট না করে থাকেন, তাহলে সমর্থিত ব্যাক নেভিগেশন এপিআই ব্যবহার করতে আপনার অ্যাপ আপডেট করুন , অথবা আপনার অ্যাপের AndroidManifest.xml ফাইলের <application> অ্যাপ্লিকেশন> বা <activity> ট্যাগে android:enableOnBackInvokedCallback অ্যাট্রিবিউটকে false সেট করে সাময়িকভাবে অপ্ট আউট করুন।

মার্জিত ফন্ট API গুলি অবমূল্যায়িত এবং অক্ষম করা হয়েছে৷

অ্যান্ড্রয়েড 15 (API স্তর 35) টার্গেট করা অ্যাপগুলির মধ্যে elegantTextHeight TextView বৈশিষ্ট্যটি ডিফল্টভাবে true হিসাবে সেট করা আছে, কমপ্যাক্ট ফন্টটিকে এমন একটি দিয়ে প্রতিস্থাপন করা যা অনেক বেশি পাঠযোগ্য। আপনি elegantTextHeight অ্যাট্রিবিউটটি false সেট করে এটিকে ওভাররাইড করতে পারেন।

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

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

Android 16 (API স্তর 36) নিম্নলিখিত পরিবর্তনগুলিকে অন্তর্ভুক্ত করে যা Android সিস্টেমের বিভিন্ন মূল ক্ষমতাগুলিকে সংশোধন বা প্রসারিত করে৷

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

Android 16 টার্গেট করার আগে, যখন scheduleAtFixedRate একটি বৈধ প্রক্রিয়া লাইফসাইকেলের বাইরে থাকার কারণে একটি টাস্ক এক্সিকিউশন মিস করে, অ্যাপটি একটি বৈধ লাইফসাইকেলে ফিরে গেলে সমস্ত মিস করা এক্সিকিউশন অবিলম্বে কার্যকর হয়।

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

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

Android 16 (API লেভেল 36) বড় স্ক্রীন ডিভাইসে প্রদর্শিত হলে অ্যাপগুলির জন্য নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে।

অভিযোজিত বিন্যাস

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

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

অ্যান্ড্রয়েড 16 (এপিআই লেভেল 36) টার্গেট করা অ্যাপগুলির জন্য, অ্যান্ড্রয়েড 16-এ সিস্টেম কীভাবে ওরিয়েন্টেশন, রিসাইজবিলিটি এবং অ্যাসপেক্ট রেশিও সীমাবদ্ধতাগুলি পরিচালনা করে তার পরিবর্তনগুলি অন্তর্ভুক্ত করে৷ সবচেয়ে ছোট প্রস্থ >= 600dp সহ ডিসপ্লেতে, বিধিনিষেধ আর প্রযোজ্য নয়। অ্যাসপেক্ট রেশিও বা ব্যবহারকারীর পছন্দের অভিযোজন নির্বিশেষে অ্যাপগুলি সম্পূর্ণ ডিসপ্লে উইন্ডোটি পূরণ করে এবং পিলারবক্সিং ব্যবহার করা হয় না।

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

আপনি অ্যাপের সামঞ্জস্যতা ফ্রেমওয়ার্ক ব্যবহার করে এবং 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 কোনো প্রভাব নেই৷

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

ব্যতিক্রম

নিম্নলিখিত পরিস্থিতিতে 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 16 (API স্তর 36) স্বাস্থ্য এবং ফিটনেস ডেটা সম্পর্কিত নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

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

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 (API লেভেল 36) পেরিফেরাল ডিভাইসগুলির সাথে সংযোগ উন্নত করতে ব্লুটুথ স্ট্যাকের নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

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

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

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

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

নিরাপত্তা

Android 16 (API স্তর 36) নিম্নলিখিত নিরাপত্তা পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

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

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this 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:")

GPU syscall ফিল্টারিং

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

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

এই পরিবর্তনটি সমর্থিত গ্রাফিক্স এপিআইগুলিকে প্রভাবিত করে না (ভুলকান এবং ওপেনজিএল সহ), এবং বিকাশকারী বা বিদ্যমান অ্যাপ্লিকেশনগুলিকে প্রভাবিত করবে বলে আশা করা যায় না। GPU প্রোফাইলিং টুল যেমন স্ট্রীমলাইন পারফরম্যান্স অ্যানালাইজার এবং Android 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 ব্যবহার করার প্রয়োজন হয়, তাহলে অনুগ্রহ করে একটি বাগ ফাইল করুন এবং এটি android-partner-security@google.com-এ বরাদ্দ করুন।

FAQ

1. এই নীতি পরিবর্তন কি সমস্ত OEM-এর ক্ষেত্রে প্রযোজ্য? এই পরিবর্তনটি অপ্ট-ইন করা হবে, তবে যেকোন OEM যারা এই শক্ত করার পদ্ধতি ব্যবহার করতে চান তাদের জন্য উপলব্ধ। পরিবর্তন বাস্তবায়নের নির্দেশাবলী বাস্তবায়ন ডকুমেন্টেশনে পাওয়া যাবে।

2. এটি কার্যকর করার জন্য OEM কোডবেসে পরিবর্তন করা কি বাধ্যতামূলক, নাকি এটি ডিফল্টরূপে একটি নতুন AOSP রিলিজের সাথে আসে? প্ল্যাটফর্ম-স্তরের পরিবর্তন ডিফল্টরূপে একটি নতুন AOSP রিলিজের সাথে আসবে। বিক্রেতারা তাদের কোডবেসে এই পরিবর্তনটি অপ্ট-ইন করতে পারে যদি তারা এটি প্রয়োগ করতে চায়৷

3. IOCTL তালিকা আপ টু ডেট রাখার জন্য SoCs কি দায়ী? উদাহরণস্বরূপ, যদি আমার ডিভাইস একটি ARM Mali GPU ব্যবহার করে, তাহলে আমাকে কি কোনো পরিবর্তনের জন্য ARM-এর সাথে যোগাযোগ করতে হবে? ড্রাইভার রিলিজের পরে পৃথক SoC গুলিকে ডিভাইস প্রতি তাদের IOCTL তালিকা আপডেট করতে হবে। উদাহরণ স্বরূপ, ARM তাদের প্রকাশিত IOCTL তালিকা ড্রাইভার আপডেটের পর আপডেট করবে। যাইহোক, OEM-দের নিশ্চিত করা উচিত যে তারা তাদের SEPpolicy-তে আপডেটগুলি অন্তর্ভুক্ত করেছে এবং প্রয়োজন অনুযায়ী তালিকায় যেকোনও নির্বাচিত কাস্টম IOCTL যোগ করেছে।

4. এই পরিবর্তনটি কি সমস্ত Pixel-এর ইন-মার্কেট ডিভাইসে স্বয়ংক্রিয়ভাবে প্রযোজ্য হয়, নাকি এই পরিবর্তনটি প্রয়োগ করার জন্য কিছু টগল করার জন্য ব্যবহারকারীর অ্যাকশন প্রয়োজন? এই পরিবর্তনটি মালি GPU (Pixel 6-9) ব্যবহার করে সমস্ত Pixel ইন-মার্কেট ডিভাইসগুলিতে প্রযোজ্য। এই পরিবর্তনটি প্রয়োগ করার জন্য কোন ব্যবহারকারীর পদক্ষেপের প্রয়োজন নেই।

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

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

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

গোপনীয়তা

Android 16 (API স্তর 36) নিম্নলিখিত গোপনীয়তা পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

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

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

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

মুক্তির পরিকল্পনা

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

প্রভাব

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

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

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

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

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

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

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

বিকাশকারী নির্দেশিকা (অপ্ট-ইন)

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

1. 25Q2 বিটা 3 বা তার পরের বিল্ডে ডিভাইসটিকে ফ্ল্যাশ করুন।
2. পরীক্ষা করার জন্য অ্যাপটি ইনস্টল করুন।

3. অ্যাডবি-তে অ্যাপকম্প্যাট পতাকা টগল করুন:

   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)

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

এই প্রকল্পে একটি স্থানীয় নেটওয়ার্ক একটি IP নেটওয়ার্ককে বোঝায় যা একটি সম্প্রচার-সক্ষম নেটওয়ার্ক ইন্টারফেস ব্যবহার করে, যেমন Wi-Fi বা ইথারনেট, কিন্তু সেলুলার (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)

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

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

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