আচরণের পরিবর্তন: 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 Beta 3, 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.

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

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

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

মার্জিত ফন্ট 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 应用，无论设备屏幕方向如何。在当今的多设备时代，限制屏幕方向和尺寸调整等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，Android 16 对系统管理屏幕方向、尺寸调整和宽高比限制的方式进行了更改。在最小宽度大于等于 600dp 的显示屏上，这些限制不再适用。无论宽高比或用户的首选屏幕方向如何，应用都会填满整个显示窗口，并且不会使用信箱模式。

此变更引入了新的标准平台行为。Android 正在朝着一种模式发展，即应用应适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或尺寸可调整性受限等限制会妨碍应用自适应，因此我们建议让应用自适应，以提供尽可能出色的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的破坏性更改

忽略屏幕方向、可调整大小和宽高比限制可能会影响应用在某些设备上的界面，尤其是专为锁定在纵向模式的小布局设计的元素：例如，拉伸的布局、屏幕外动画和组件等问题。对宽高比或屏幕方向做出的任何假设都可能会导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致重新创建更多 activity，如果未正确保留用户状态，可能会导致丢失用户状态。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在大屏设备上，以下清单属性和运行时 API 会在全屏和多窗口模式下被忽略：

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

系统会忽略 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的以下值：

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

关于显示屏可调整大小，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 没有任何影响。

对于以 Android 16（API 级别 36）为目标平台的应用，系统会默认在大屏设备上忽略应用屏幕方向、可调整大小和宽高比限制，但所有尚未完全准备就绪的应用都可以通过选择停用此功能来暂时替换此行为（这会导致应用进入兼容模式，即之前的行为）。

异常

在以下情况下，Android 16 的屏幕方向、尺寸调整和宽高比限制不适用：

• 游戏（基于 android:appCategory 标志）
• 用户在设备的宽高比设置中明确选择启用应用的默认行为
• 小于 sw600dp 的屏幕

暂时停用

如需停用特定 activity，请声明 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 are transitioning to the granular permissions under android.permissions.health also used by Health Connect. Any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND now requires the corresponding android.permissions.health permission. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Wear Health Services
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from Wear ProtoLayout
• 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 now 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.

If your app currently uses custom mechanisms for bond loss handling, migrate to the new intent ACTION_KEY_MISSING to detect and manage bond loss events. We recommend your app guide the user to confirm the remote device is in range before initiating device forgetting and re-pairing.

Moreover, if a device disconnects after ACTION_KEY_MISSING intent is received, your app should be mindful about reconnecting to the device as that device may no longer be bonded with the system.

নিরাপত্তা

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) নিম্নলিখিত গোপনীয়তা পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

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

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and TBD respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

IPv4:

• 169.254.0.0/16 // Link Local
• 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:

• Link-local
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

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

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