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

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

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

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

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

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

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.

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

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

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

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

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

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

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

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

Android 16 (API লেভেল 36) বা তার বেশির অ্যাপ্লিকেশানগুলির জন্য, BODY_SENSORS অনুমতিগুলি android.permissions.health এর অধীনে আরও দানাদার অনুমতি ব্যবহার করে, যা Health Connect ও ব্যবহার করে৷ অ্যান্ড্রয়েড 16 অনুযায়ী, যে কোনো API এর আগে BODY_SENSORS বা BODY_SENSORS_BACKGROUND জন্য সংশ্লিষ্ট android.permissions.health অনুমতি প্রয়োজন। এটি নিম্নলিখিত ডেটা প্রকার, API এবং ফোরগ্রাউন্ড পরিষেবার প্রকারগুলিকে প্রভাবিত করে:

• Wear OS-এ স্বাস্থ্য পরিষেবা থেকে HEART_RATE_BPM
• Android সেন্সর ম্যানেজার থেকে Sensor.TYPE_HEART_RATE
• Wear OS-এ ProtoLayout থেকে heartRateAccuracy এবং heartRateBpm
• 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 অনুরোধ করুন।

এই অনুমতিগুলি স্বাস্থ্য, ফিটনেস এবং সুস্থতার ডেটার জন্য Android ডেটাস্টোর Health Connect থেকে ডেটা পড়ার অ্যাক্সেস রক্ষা করে সেই অনুমতিগুলির মতোই৷

মোবাইল অ্যাপস

READ_HEART_RATE এবং অন্যান্য দানাদার অনুমতিগুলি ব্যবহার করার জন্য মাইগ্রেট করা মোবাইল অ্যাপগুলিকে অবশ্যই অ্যাপের গোপনীয়তা নীতি প্রদর্শনের জন্য একটি কার্যকলাপ ঘোষণা করতে হবে। এটি স্বাস্থ্য সংযোগের মতো একই প্রয়োজনীয়তা।

সংযোগ

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.

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

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.

নিরাপত্তা

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:")

গোপনীয়তা

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

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

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.