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

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

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

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

Android 15 অ্যান্ড্রয়েড সিস্টেমের বিভিন্ন মূল ক্ষমতাগুলিকে সংশোধন বা প্রসারিত করে।

ফোরগ্রাউন্ড পরিষেবাতে পরিবর্তন

আমরা Android 15 এর সাথে ফোরগ্রাউন্ড পরিষেবাগুলিতে নিম্নলিখিত পরিবর্তনগুলি করছি৷

ডেটা সিঙ্ক ফোরগ্রাউন্ড পরিষেবা সময় শেষ আচরণ

对于以 Android 15（API 级别 35）或更高版本为目标平台的应用，Android 15 为 dataSync 引入了新的超时行为。此行为也适用于新的 mediaProcessing 前台服务类型。

系统允许应用的 dataSync 服务在 24 小时内共运行 6 小时，之后系统会调用正在运行的服务的 Service.onTimeout(int, int) 方法（在 Android 15 中引入）。此时，服务有几秒钟的时间来调用 Service.stopSelf()。调用 Service.onTimeout() 后，该服务将不再被视为前台服务。如果服务未调用 Service.stopSelf()，系统会抛出内部异常。系统会在 Logcat 中记录此异常，并显示以下消息：

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

为避免此行为变更出现问题，您可以执行以下一项或多项操作：

  1. 让您的服务实现新的 Service.onTimeout(int, int) 方法。当应用收到回调时，请务必在几秒钟内调用 stopSelf()。（如果您不立即停止应用，系统会生成故障。）
  2. 确保应用的 dataSync 服务在任何 24 小时内总运行时间不超过 6 小时（除非用户与应用互动，重置计时器）。
  3. 仅在有直接用户互动时启动 dataSync 前台服务；由于服务启动时应用位于前台，因此您的服务在应用进入后台后有完整的 6 小时时间。
  4. 请使用替代 API，而不是使用 dataSync 前台服务。

如果您的应用的 dataSync 前台服务在过去 24 小时内运行了 6 小时，则您无法启动其他 dataSync 前台服务，除非用户已将您的应用切换到前台（这会重置计时器）。如果您尝试启动其他 dataSync 前台服务，系统会抛出 ForegroundServiceStartNotAllowedException，并显示类似“前台服务类型 dataSync 的时间限制已用尽”的错误消息。

测试

如需测试应用的行为，即使您的应用并非以 Android 15 为目标平台（只要该应用在 Android 15 设备上运行），您也可以启用数据同步超时。如需启用超时，请运行以下 adb 命令：

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

您还可以调整超时期限，以便更轻松地测试应用在达到上限时的行为方式。如需设置新的超时期限，请运行以下 adb 命令：

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

নতুন মিডিয়া প্রক্রিয়াকরণ ফোরগ্রাউন্ড পরিষেবার ধরন

Android 15 引入了一种新的前台服务类型 mediaProcessing。此服务类型适用于转码媒体文件等操作。例如，媒体应用可能会下载音频文件，并需要先将其转换为其他格式，然后才能播放。您可以使用 mediaProcessing 前台服务，确保即使应用在后台运行时转换也会继续。

系统允许应用的 mediaProcessing 服务在 24 小时内总共运行 6 小时，之后系统会调用正在运行的服务的 Service.onTimeout(int, int) 方法（在 Android 15 中引入）。此时，服务有几秒钟的时间来调用 Service.stopSelf()。如果服务未调用 Service.stopSelf()，系统会抛出内部异常。系统会在 Logcat 中记录此异常，并显示以下消息：

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

为避免出现此异常，您可以执行以下任一操作：

  1. 让您的服务实现新的 Service.onTimeout(int, int) 方法。当您的应用收到回调时，请务必在几秒钟内调用 stopSelf()。（如果您未立即停止应用，系统会生成失败情况。）
  2. 确保应用的 mediaProcessing 服务在任何 24 小时内总运行时间不超过 6 小时（除非用户与应用互动，重置计时器）。
  3. 仅在有直接用户互动时启动 mediaProcessing 前台服务；由于服务启动时应用位于前台，因此您的服务在应用进入后台后有完整的 6 小时时间。
  4. 请改用 替代 API（例如 WorkManager），而不是使用 mediaProcessing 前台服务。

如果您的应用的 mediaProcessing 前台服务在过去 24 小时内运行了 6 小时，则您无法启动其他 mediaProcessing 前台服务，除非用户将您的应用切换到前台（这会重置计时器）。如果您尝试启动另一个 mediaProcessing 前台服务，系统会抛出 ForegroundServiceStartNotAllowedException，并显示类似于“前台服务类型 mediaProcessing 的时间限制已用尽”的错误消息。

如需详细了解 mediaProcessing 服务类型，请参阅 Android 15 前台服务类型变更：媒体处理。

测试

如需测试应用的行为，您可以启用媒体处理超时，即使您的应用并非以 Android 15 为目标平台也是如此（前提是应用在 Android 15 设备上运行）。如需启用超时，请运行以下 adb 命令：

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

您还可以调整超时期限，以便更轻松地测试应用在达到上限时的行为方式。如需设置新的超时期限，请运行以下 adb 命令：

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

BOOT_COMPLETED সম্প্রচার রিসিভার ফোরগ্রাউন্ড পরিষেবা চালু করার উপর নিষেধাজ্ঞা

在启动 BOOT_COMPLETED 广播接收器方面存在新限制 前台服务。BOOT_COMPLETED 接收器不能启动 以下类型的前台服务：

如果 BOOT_COMPLETED 接收器尝试启动任何上述类型的前台 服务，系统会抛出 ForegroundServiceStartNotAllowedException。

测试

如需测试应用的行为，您可以启用这些新限制，即使您的应用并未以 Android 15 为目标平台（只要应用在 Android 15 设备上运行）也是如此。运行以下 adb 命令：

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

如需在不重启设备的情况下发送 BOOT_COMPLETED 广播，请运行以下 adb 命令：

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name

একটি অ্যাপের SYSTEM_ALERT_WINDOW অনুমতি থাকাকালীন ফোরগ্রাউন্ড পরিষেবাগুলি শুরু করার উপর বিধিনিষেধ

以前，如果应用拥有 SYSTEM_ALERT_WINDOW 权限，即使应用当前在后台运行，也可以启动前台服务（如免于后台启动限制中所述）。

如果应用以 Android 15 为目标平台，则此豁免范围现在更窄。现在，应用需要具有 SYSTEM_ALERT_WINDOW 权限，并且还需要有一个可见的叠加窗口。也就是说，应用需要先启动 TYPE_APPLICATION_OVERLAY 窗口，并且该窗口需要处于可见状态，然后您才能启动前台服务。

如果您的应用尝试从后台启动前台服务，但不符合这些新要求（并且没有其他豁免情况），系统会抛出 ForegroundServiceStartNotAllowedException。

如果您的应用声明了 SYSTEM_ALERT_WINDOW 权限并从后台启动前台服务，则可能会受到此变更的影响。如果您的应用获得了 ForegroundServiceStartNotAllowedException，请检查应用的操作顺序，并确保应用在尝试从后台启动前台服务之前已具有有效的叠加层窗口。您可以通过调用 View.getWindowVisibility() 检查叠加层窗口当前是否可见，也可以替换 View.onWindowVisibilityChanged()，以便在可见性发生变化时收到通知。

测试

如需测试应用的行为，您可以启用这些新限制，即使您的应用并未以 Android 15 为目标平台（只要应用在 Android 15 设备上运行）也是如此。如需针对从后台启动前台服务启用这些新限制，请运行以下 adb 命令：

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

অ্যাপ্লিকেশানগুলি কখন বিরক্ত করবে না মোডের বৈশ্বিক অবস্থা পরিবর্তন করতে পারে তার পরিবর্তন৷

以 Android 15 为目标平台的应用无法再更改设备上的全局状态或勿扰 (DND) 政策（通过修改用户设置或关闭 DND 模式）。相反，应用必须提供一个 AutomaticZenRule，系统会将后者合并到一个具有现有最严格的政策胜出方案的全局政策中。调用之前影响全局状态的现有 API（setInterruptionFilter、setNotificationPolicy）会导致创建或更新隐式 AutomaticZenRule，该 AutomaticZenRule 根据这些 API 调用的调用周期而开启或关闭。

请注意，只有在应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL) 且预期调用会停用之前由其所有者激活的 AutomaticZenRule 时，此变更才会影响可观察的行为。

OpenJDK API পরিবর্তন

Android 15 সর্বশেষ OpenJDK LTS রিলিজের বৈশিষ্ট্যগুলির সাথে সারিবদ্ধ করার জন্য Android এর মূল লাইব্রেরিগুলিকে রিফ্রেশ করার কাজ চালিয়ে যাচ্ছে।

এই পরিবর্তনগুলির মধ্যে কিছু Android 15 (API স্তর 35) টার্গেট করা অ্যাপগুলির জন্য অ্যাপের সামঞ্জস্যকে প্রভাবিত করতে পারে:

  • স্ট্রিং ফরম্যাটিং API-তে পরিবর্তন : নিম্নলিখিত String.format() এবং Formatter.format() API ব্যবহার করার সময় আর্গুমেন্ট ইনডেক্স, ফ্ল্যাগ, প্রস্থ এবং নির্ভুলতার বৈধতা এখন আরও কঠোর:

    উদাহরণস্বরূপ, নিম্নলিখিত ব্যতিক্রমটি ছুঁড়ে দেওয়া হয় যখন 0 এর একটি আর্গুমেন্ট সূচক ব্যবহার করা হয় ( %0 বিন্যাসে স্ট্রিং):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0

    এই ক্ষেত্রে, 1 এর আর্গুমেন্ট ইনডেক্স ব্যবহার করে সমস্যাটি ঠিক করা যেতে পারে ( ফরম্যাট স্ট্রিংয়ে %1 )।

  • Arrays.asList(...).toArray() এর কম্পোনেন্ট প্রকারে পরিবর্তন : Arrays.asList(...).toArray() ব্যবহার করার সময়, ফলাফল পাওয়া অ্যারের কম্পোনেন্ট টাইপ এখন একটি Object -এর প্রকার নয়। অন্তর্নিহিত অ্যারের উপাদান। সুতরাং নিম্নলিখিত কোডটি একটি ClassCastException নিক্ষেপ করে:

    String[] elements = (String[]) Arrays.asList("one", "two").toArray();

    এই ক্ষেত্রে, String কম্পোনেন্ট টাইপ হিসাবে ফলস্বরূপ অ্যারে সংরক্ষণ করতে, আপনি পরিবর্তে Collection.toArray(Object[]) ব্যবহার করতে পারেন:

    String[] elements = Arrays.asList("two", "one").toArray(new String[0]);

  • ভাষা কোড পরিচালনায় পরিবর্তন : Locale API ব্যবহার করার সময়, হিব্রু, ইদ্দিশ এবং ইন্দোনেশিয়ান ভাষার কোডগুলি আর তাদের অপ্রচলিত ফর্মগুলিতে রূপান্তরিত হয় না (হিব্রু: iw , য়িদ্দিশ: ji , এবং ইন্দোনেশিয়ান: in )। এই লোকেলগুলির মধ্যে একটির জন্য ভাষা কোড নির্দিষ্ট করার সময়, পরিবর্তে ISO 639-1 থেকে কোডগুলি ব্যবহার করুন (হিব্রু: he , য়িদ্দিশ: yi , এবং ইন্দোনেশিয়ান: id )।

  • এলোমেলো int সিকোয়েন্সে পরিবর্তন : https://bugs.openjdk.org/browse/JDK-8301574- এ করা পরিবর্তনগুলি অনুসরণ করে, নিম্নলিখিত Random.ints() পদ্ধতিগুলি এখন Random.nextInt() পদ্ধতিগুলির থেকে সংখ্যার একটি ভিন্ন ক্রম ফেরত দেয় করো:

    সাধারণত, এই পরিবর্তনের ফলে অ্যাপ-ব্রেকিং আচরণ করা উচিত নয়, তবে আপনার কোড Random.ints() পদ্ধতি থেকে তৈরি হওয়া ক্রম Random.nextInt() সাথে মিলবে বলে আশা করা উচিত নয়।

আপনি Android 15 (API স্তর 35) ব্যবহার করার জন্য আপনার অ্যাপের বিল্ড কনফিগারেশনে compileSdk আপডেট করার পরে নতুন SequencedCollection API আপনার অ্যাপের সামঞ্জস্যকে প্রভাবিত করতে পারে :

  • kotlin-stdlib এ MutableList.removeFirst() এবং MutableList.removeLast() এক্সটেনশন ফাংশনের সাথে সংঘর্ষ

    জাভাতে List ধরনটি Kotlin-এর MutableList প্রকারে ম্যাপ করা হয়েছে। যেহেতু List.removeFirst() এবং List.removeLast() APIগুলি অ্যান্ড্রয়েড 15 (API স্তর 35) এ চালু করা হয়েছে, তাই Kotlin কম্পাইলার ফাংশন কলগুলি সমাধান করে, উদাহরণস্বরূপ list.removeFirst() , স্থিরভাবে নতুন List API-এর পরিবর্তে kotlin-stdlib এ এক্সটেনশন ফাংশন।

    যদি একটি অ্যাপ পুনরায় কম্পাইল করা হয় compileSdk 35 সেট করে এবং minSdk সেট করে 34 বা তার নিচে, এবং তারপরে অ্যাপটি Android 14 এবং তার নিচের সংস্করণে চালানো হয়, একটি রানটাইম ত্রুটি নিক্ষেপ করা হয়:

    java.lang.NoSuchMethodError: No virtual method
removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;

    Android Gradle Plugin-এ বিদ্যমান NewApi lint বিকল্পটি এই নতুন API ব্যবহারগুলি ধরতে পারে।

    ./gradlew lint

MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
      list.removeFirst()

    রানটাইম ব্যতিক্রম এবং লিন্ট ত্রুটিগুলি ঠিক করতে, Kotlin-এ removeFirst() এবং removeLast() ফাংশন কল যথাক্রমে removeAt(0) এবং removeAt(list.lastIndex) দিয়ে প্রতিস্থাপন করা যেতে পারে। আপনি যদি Android Studio Ladybug ব্যবহার করেন | 2024.1.3 বা উচ্চতর, এটি এই ত্রুটিগুলির জন্য একটি দ্রুত সমাধানের বিকল্পও প্রদান করে।

    @SuppressLint("NewApi") অপসারণ করার কথা বিবেচনা করুন এবং লিন্ট বিকল্পটি নিষ্ক্রিয় করা থাকলে lintOptions { disable 'NewApi' } ।

  • জাভাতে অন্যান্য পদ্ধতির সাথে সংঘর্ষ

    বিদ্যমান প্রকারগুলিতে নতুন পদ্ধতি যোগ করা হয়েছে, উদাহরণস্বরূপ, List এবং Deque । এই নতুন পদ্ধতিগুলি অন্যান্য ইন্টারফেস এবং ক্লাসে একই নাম এবং আর্গুমেন্ট প্রকারের পদ্ধতিগুলির সাথে সামঞ্জস্যপূর্ণ নাও হতে পারে। অসঙ্গতি সহ একটি পদ্ধতি স্বাক্ষর সংঘর্ষের ক্ষেত্রে, javac কম্পাইলার একটি বিল্ড-টাইম ত্রুটি আউটপুট করে। যেমন:

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

    javac MyList.java

MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List
  public void removeLast() {
              ^
  return type void is not compatible with Object
  where E is a type-variable:
    E extends Object declared in interface List

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

    javac MyList.java

MyList.java:7: error: types Deque<Object> and List<Object> are incompatible;
public class MyList implements  List<Object>, Deque<Object> {
  both define reversed(), but with unrelated return types
1 error

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

    javac MyList.java

MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible;
public static class MyList implements List<Object>, MyInterface<Object> {
  class MyList inherits unrelated defaults for getFirst() from types List and MyInterface
  where E#1,E#2 are type-variables:
    E#1 extends Object declared in interface List
    E#2 extends Object declared in interface MyInterface
1 error

    এই বিল্ড ত্রুটিগুলি ঠিক করার জন্য, এই ইন্টারফেসগুলি বাস্তবায়নকারী ক্লাসটি একটি সামঞ্জস্যপূর্ণ রিটার্ন টাইপের সাথে পদ্ধতিটিকে ওভাররাইড করবে। যেমন:

    @Override
public Object getFirst() {
    return List.super.getFirst();
}

নিরাপত্তা

অ্যান্ড্রয়েড 15-এ এমন পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে যা অ্যাপ এবং ব্যবহারকারীদের ক্ষতিকারক অ্যাপ থেকে রক্ষা করতে সিস্টেম নিরাপত্তার প্রচার করে।

সুরক্ষিত ব্যাকগ্রাউন্ড কার্যকলাপ চালু হয়

Android 15 可保护用户免受恶意应用的侵害，并让用户更好地控制 来防止恶意后台应用 将其他应用置于前台、提升其权限以及滥用 用户互动自以下时间以来，后台活动启动一直受到限制 Android 10（API 级别 29）。

禁止与堆栈中的顶部 UID 不匹配的应用启动 activity

恶意应用可以在同一任务中启动另一个应用的 activity，然后 叠加在上面，营造出像该应用一样的错觉。这个“任务” 劫持"攻击绕过了当前的后台启动限制， 会发生在同一个可见任务中。为了降低这种风险，Android 15 新增了 用于阻止与堆栈中的顶层 UID 不匹配的应用启动的标志 活动。如需选择启用应用的所有活动，请更新 allowCrossUidActivitySwitchFromBelow 属性：AndroidManifest.xml

<application android:allowCrossUidActivitySwitchFromBelow="false" >

如果满足以下所有条件，则启用新的安全措施：

  • 执行启动的应用以 Android 15 为目标平台。
  • 任务堆栈顶部的应用以 Android 15 为目标平台。
  • 所有可见活动都已选择启用新保护措施

如果启用了安全措施，应用可能会返回主屏幕，而不是返回 最后一个可见应用（如果他们自行完成任务）。

其他变更

除了限制 UID 匹配之外，这些其他变更也 包括：

  • 更改 PendingIntent 创作者，以阻止后台活动启动，具体方法是： 默认。这有助于防止应用意外创建 可能被恶意操作者滥用的 PendingIntent。
  • 请勿将应用调到前台，除非 PendingIntent 发送者 允许它。此变更旨在防止恶意应用滥用 在后台启动 activity 的功能。默认情况下，应用 允许将任务堆栈转到前台，除非创建者允许 后台活动启动权限或发送者有后台活动 启动权限
  • 控制任务堆栈的顶层 activity 完成其任务的方式。如果 顶层 activity 完成一项任务后，Android 会返回到之前执行的 上次活动时间。此外，如果非顶层 activity 完成其任务，Android 将 返回主屏幕；因此不会阻碍这个非顶层的 活动。
  • 防止将其他应用中的任意 activity 启动到您自己的 activity 任务。这项变更旨在防止恶意应用 看起来像是来自其他应用的活动
  • 禁止将不可见窗口视为后台活动 发布。这有助于防止恶意应用滥用后台 activity 来向用户显示不需要或恶意的内容。

নিরাপদ অভিপ্রায়

Android 15 引入了新的可选安全措施，以提高 intent 的安全性和稳健性。这些变更旨在防止潜在的漏洞以及恶意应用可能利用的 intent 滥用行为。Android 15 对 intent 的安全性进行了两项主要改进：

  • 与目标 intent 过滤器匹配：定位到特定组件的 intent 必须与目标的 intent 过滤器规范完全匹配。如果您发送 intent 来启动其他应用的 activity，目标 intent 组件需要与接收 activity 声明的 intent 过滤器保持一致。
  • intent 必须具有操作：没有操作的 intent 将不再与任何 intent 过滤器匹配。这意味着，用于启动 activity 或服务的 intent 必须具有明确定义的操作。

如需检查您的应用对这些更改的响应方式，请在应用中使用 StrictMode。如需查看有关 Intent 使用违规行为的详细日志，请添加以下方法：

Kotlin


fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

Java


public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

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

অ্যান্ড্রয়েড 15-এ এমন কিছু পরিবর্তন রয়েছে যা আরও সামঞ্জস্যপূর্ণ, স্বজ্ঞাত ব্যবহারকারীর অভিজ্ঞতা তৈরি করার উদ্দেশ্যে করা হয়েছে।

উইন্ডো ইনসেট পরিবর্তন

Android 15 中有两个与窗口边衬区相关的变更：默认强制执行无边框模式；还存在配置变更，例如系统栏的默认配置。

全面实施政策

অ্যাপ্লিকেশানগুলি যদি Android 15 (API স্তর 35) কে লক্ষ্য করে তাহলে Android 15 চালিত ডিভাইসগুলিতে ডিফল্টরূপে এজ-টু-এজ থাকে৷

একটি অ্যাপ যা Android 14 কে লক্ষ্য করে এবং একটি Android 15 ডিভাইসে এজ-টু-এজ নয়।


একটি অ্যাপ যা Android 15 (API লেভেল 35) কে লক্ষ্য করে এবং একটি Android 15 ডিভাইসে এজ-টু-এজ। এই অ্যাপটি বেশিরভাগ উপাদান 3 রচনা উপাদান ব্যবহার করে যা স্বয়ংক্রিয়ভাবে ইনসেটগুলি প্রয়োগ করে। এই স্ক্রীনটি Android 15 এজ-টু-এজ এনফোর্সমেন্ট দ্বারা নেতিবাচকভাবে প্রভাবিত হয় না।

এটি একটি ব্রেকিং পরিবর্তন যা আপনার অ্যাপের UI কে নেতিবাচকভাবে প্রভাবিত করতে পারে। পরিবর্তনগুলি নিম্নলিখিত UI অঞ্চলগুলিকে প্রভাবিত করে:

  • অঙ্গভঙ্গি হ্যান্ডেল নেভিগেশন বার
    • ডিফল্টরূপে স্বচ্ছ।
    • নীচের অফসেট অক্ষম করা হয়েছে তাই ইনসেটগুলি প্রয়োগ করা না হলে বিষয়বস্তু সিস্টেম নেভিগেশন বারের পিছনে চলে যায়৷
    • setNavigationBarColor এবং R.attr#navigationBarColor বাতিল করা হয়েছে এবং অঙ্গভঙ্গি নেভিগেশনকে প্রভাবিত করে না।
    • setNavigationBarContrastEnforced এবং R.attr#navigationBarContrastEnforced জেসচার নেভিগেশনের উপর কোন প্রভাব নেই।
  • 3-বোতাম নেভিগেশন
    • অস্বচ্ছতা ডিফল্টরূপে 80% এ সেট করা হয়েছে, সম্ভবত উইন্ডোর পটভূমির সাথে রঙের সাথে মিল রয়েছে।
    • নীচের অফসেট অক্ষম করা হয়েছে যাতে ইনসেটগুলি প্রয়োগ না করা হলে বিষয়বস্তু সিস্টেম নেভিগেশন বারের পিছনে চলে যায়৷
    • setNavigationBarColor এবং R.attr#navigationBarColor ডিফল্টরূপে উইন্ডোর পটভূমির সাথে মেলে সেট করা আছে। এই ডিফল্টটি প্রয়োগ করার জন্য উইন্ডোর পটভূমিতে অবশ্যই একটি রঙ আঁকতে হবে। এই APIটি বাতিল করা হয়েছে কিন্তু 3-বোতাম নেভিগেশনকে প্রভাবিত করে চলেছে৷
    • setNavigationBarContrastEnforced এবং R.attr#navigationBarContrastEnforced ডিফল্টভাবে সত্য, যা 3-বোতাম নেভিগেশন জুড়ে একটি 80% অস্বচ্ছ পটভূমি যোগ করে।
  • স্ট্যাটাস বার
    • ডিফল্টরূপে স্বচ্ছ।
    • শীর্ষ অফসেটটি অক্ষম করা হয়েছে তাই ইনসেটগুলি প্রয়োগ করা না হলে বিষয়বস্তু স্ট্যাটাস বারের পিছনে চলে যায়৷
    • setStatusBarColor এবং R.attr#statusBarColor বাতিল করা হয়েছে এবং Android 15-এ কোনো প্রভাব নেই।
    • setStatusBarContrastEnforced এবং R.attr#statusBarContrastEnforced বাতিল করা হয়েছে কিন্তু এখনও Android 15-এ এর প্রভাব রয়েছে।
  • ডিসপ্লে কাটআউট
    • নন-ফ্লোটিং উইন্ডোগুলির layoutInDisplayCutoutMode অবশ্যই LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS হতে হবে। SHORT_EDGES , NEVER , এবং DEFAULT ALWAYS হিসাবে ব্যাখ্যা করা হয় যাতে ব্যবহারকারীরা ডিসপ্লে কাটআউটের কারণে একটি কালো বার দেখতে না পায় এবং প্রান্ত থেকে প্রান্তে প্রদর্শিত হয়৷

নিম্নলিখিত উদাহরণটি Android 15 (API স্তর 35) লক্ষ্য করার আগে এবং পরে এবং ইনসেটগুলি প্রয়োগ করার আগে এবং পরে একটি অ্যাপ দেখায়।

একটি অ্যাপ যা Android 14 কে লক্ষ্য করে এবং একটি Android 15 ডিভাইসে এজ-টু-এজ নয়।
একটি অ্যাপ যা Android 15 (API লেভেল 35) কে লক্ষ্য করে এবং একটি Android 15 ডিভাইসে এজ-টু-এজ। যাইহোক, অ্যান্ড্রয়েড 15 এজ-টু-এজ এনফোর্সমেন্টের কারণে স্ট্যাটাস বার, 3-বোতাম নেভিগেশন বার, বা ডিসপ্লে কাটআউট দ্বারা অনেক উপাদান লুকানো আছে। লুকানো UI এর মধ্যে রয়েছে উপাদান 2 শীর্ষ অ্যাপ বার, ফ্লোটিং অ্যাকশন বোতাম এবং তালিকা আইটেম।
একটি অ্যাপ যা Android 15 (API স্তর 35) কে লক্ষ্য করে, একটি Android 15 ডিভাইসে প্রান্ত থেকে প্রান্তে থাকে এবং ইনসেটগুলি প্রয়োগ করে যাতে UI লুকানো না হয়।
আপনার অ্যাপটি ইতিমধ্যেই এজ-টু-এজ কিনা তা পরীক্ষা করতে হবে

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

  • আপনার কাছে একটি নন-ফ্লোটিং উইন্ডো আছে, যেমন একটি Activity যা LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS এর পরিবর্তে SHORT_EDGES , NEVER বা DEFAULT ব্যবহার করে। আপনার অ্যাপ লঞ্চের সময় ক্র্যাশ হলে, এটি আপনার স্প্ল্যাশস্ক্রিনের কারণে হতে পারে। আপনি হয় কোর স্প্ল্যাশস্ক্রিন নির্ভরতাকে 1.2.0-alpha01 বা পরবর্তীতে আপগ্রেড করতে পারেন অথবা window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always সেট করতে পারেন।
  • আবদ্ধ UI সহ নিম্ন-ট্রাফিক স্ক্রীন থাকতে পারে। এই কম পরিদর্শন করা স্ক্রীনে UI আটকানো নেই তা যাচাই করুন। নিম্ন-ট্র্যাফিক স্ক্রিনগুলির মধ্যে রয়েছে:
    • অনবোর্ডিং বা সাইন-ইন স্ক্রীন
    • সেটিংস পৃষ্ঠা
আপনার অ্যাপ ইতিমধ্যেই এজ-টু-এজ না হলে কী পরীক্ষা করবেন

যদি আপনার অ্যাপ ইতিমধ্যেই এজ-টু-এজ না হয়, তাহলে আপনি সম্ভবত প্রভাবিত হবেন। ইতিমধ্যেই এজ-টু-এজ অ্যাপ্লিকেশানগুলির জন্য পরিস্থিতিগুলি ছাড়াও, আপনার নিম্নলিখিতগুলি বিবেচনা করা উচিত:

  • যদি আপনার অ্যাপটি কম্পোজে Material 3 উপাদান ( androidx.compose.material3 ) ব্যবহার করে, যেমন TopAppBar , BottomAppBar , এবং NavigationBar , তাহলে এই উপাদানগুলি সম্ভবত প্রভাবিত হবে না কারণ তারা স্বয়ংক্রিয়ভাবে ইনসেটগুলি পরিচালনা করে৷
  • যদি আপনার অ্যাপটি রচনায় উপাদান 2 উপাদান ( androidx.compose.material ) ব্যবহার করে, তাহলে এই উপাদানগুলি স্বয়ংক্রিয়ভাবে ইনসেটগুলি পরিচালনা করে না৷ যাইহোক, আপনি ইনসেটগুলিতে অ্যাক্সেস পেতে পারেন এবং সেগুলি ম্যানুয়ালি প্রয়োগ করতে পারেন। androidx.compose.material 1.6.0 এবং পরবর্তীতে, BottomAppBar , TopAppBar , BottomNavigation এবং NavigationRail জন্য ম্যানুয়ালি ইনসেটগুলি প্রয়োগ করতে windowInsets প্যারামিটার ব্যবহার করুন। একইভাবে, Scaffold জন্য contentWindowInsets প্যারামিটার ব্যবহার করুন।
  • যদি আপনার অ্যাপটি ভিউ এবং ম্যাটেরিয়াল কম্পোনেন্ট ( com.google.android.material ) ব্যবহার করে, তবে বেশিরভাগ ভিউ-ভিত্তিক মেটেরিয়াল কম্পোনেন্ট যেমন BottomNavigationView , BottomAppBar , NavigationRailView , বা NavigationView , ইনসেটগুলি পরিচালনা করে এবং কোনও অতিরিক্ত কাজের প্রয়োজন নেই৷ যাইহোক, AppBarLayout ব্যবহার করলে আপনাকে android:fitsSystemWindows="true" যোগ করতে হবে।
  • কাস্টম কম্পোজেবলের জন্য, প্যাডিং হিসাবে ম্যানুয়ালি ইনসেটগুলি প্রয়োগ করুন। যদি আপনার বিষয়বস্তু একটি Scaffold মধ্যে থাকে, তাহলে আপনি Scaffold প্যাডিং মান ব্যবহার করে ইনসেটগুলি ব্যবহার করতে পারেন৷ অন্যথায়, একটি WindowInsets ব্যবহার করে প্যাডিং প্রয়োগ করুন।
  • আপনার অ্যাপ যদি ভিউ এবং BottomSheet , SideSheet বা কাস্টম কন্টেনার ব্যবহার করে, তাহলে ViewCompat.setOnApplyWindowInsetsListener ব্যবহার করে প্যাডিং প্রয়োগ করুন। RecyclerView এর জন্য, এই শ্রোতা ব্যবহার করে প্যাডিং প্রয়োগ করুন এবং clipToPadding="false" যোগ করুন।
আপনার অ্যাপটি অবশ্যই কাস্টম ব্যাকগ্রাউন্ড সুরক্ষা প্রদান করবে কিনা তা পরীক্ষা করতে হবে

যদি আপনার অ্যাপটি অবশ্যই 3-বোতাম নেভিগেশন বা স্ট্যাটাস বারে কাস্টম ব্যাকগ্রাউন্ড সুরক্ষা প্রদান করে, আপনার অ্যাপটি 3-বোতাম নেভিগেশন বারের উচ্চতা বা WindowInsets.Type#statusBars পেতে WindowInsets.Type#tappableElement() ব্যবহার করে সিস্টেম বারের পিছনে একটি কম্পোজযোগ্য বা ভিউ স্থাপন করা উচিত। WindowInsets.Type#statusBars ।

অতিরিক্ত এজ-টু-এজ রিসোর্স

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

অপ্রচলিত API

নিম্নোক্ত APIগুলিকে অবমূল্যায়ন করা হয়েছে কিন্তু নিষ্ক্রিয় করা হয়নি:

নিম্নোক্ত API গুলি অবমূল্যায়িত এবং অক্ষম করা হয়েছে:

稳定配置

যদি আপনার অ্যাপটি Android 15 (API লেভেল 35) বা উচ্চতরকে লক্ষ্য করে, Configuration আর সিস্টেম বারগুলিকে বাদ দেয় না। আপনি যদি বিন্যাস গণনার জন্য Configuration ক্লাসে স্ক্রীনের আকার ব্যবহার করেন, তাহলে আপনার প্রয়োজনের উপর নির্ভর করে একটি উপযুক্ত ViewGroup , WindowInsets বা WindowMetricsCalculator মতো আরও ভাল বিকল্প দিয়ে প্রতিস্থাপন করা উচিত।

API 1 থেকে Configuration উপলব্ধ। এটি সাধারণত Activity.onConfigurationChanged থেকে প্রাপ্ত হয়। এটি জানালার ঘনত্ব, অভিযোজন এবং আকারের মতো তথ্য প্রদান করে। Configuration থেকে প্রত্যাবর্তিত উইন্ডোর আকার সম্পর্কে একটি গুরুত্বপূর্ণ বৈশিষ্ট্য হল যে এটি পূর্বে সিস্টেম বারগুলিকে বাদ দিয়েছিল।

কনফিগারেশন আকার সাধারণত সম্পদ নির্বাচনের জন্য ব্যবহৃত হয়, যেমন /res/layout-h500dp , এবং এটি এখনও একটি বৈধ ব্যবহারের ক্ষেত্রে। যাইহোক, লেআউট গণনার জন্য এটি ব্যবহার করা সবসময় নিরুৎসাহিত করা হয়েছে। আপনি যদি তা করেন তবে আপনার এখনই এটি থেকে দূরে সরে যাওয়া উচিত। আপনার ব্যবহারের ক্ষেত্রে নির্ভর করে আরও উপযুক্ত কিছু দিয়ে Configuration ব্যবহার প্রতিস্থাপন করা উচিত।

আপনি যদি লেআউটটি গণনা করতে এটি ব্যবহার করেন, তাহলে একটি উপযুক্ত ViewGroup ব্যবহার করুন, যেমন CoordinatorLayout বা ConstraintLayout । আপনি যদি সিস্টেম ন্যাভিবারের উচ্চতা নির্ধারণ করতে এটি ব্যবহার করেন, WindowInsets ব্যবহার করুন। আপনি যদি আপনার অ্যাপ উইন্ডোর বর্তমান আকার জানতে চান তাহলে computeCurrentWindowMetrics ব্যবহার করুন।

নিম্নলিখিত তালিকা এই পরিবর্তন দ্বারা প্রভাবিত ক্ষেত্র বর্ণনা করে:

  • Configuration.screenWidthDp এবং screenHeightDp মাপ আর সিস্টেম বার বাদ দেয় না।
  • Configuration.smallestScreenWidthDp পরোক্ষভাবে screenWidthDp এবং screenHeightDp এর পরিবর্তন দ্বারা প্রভাবিত হয়।
  • Configuration.orientation পরোক্ষভাবে ক্লোজ-টু-স্কোয়ার ডিভাইসে screenWidthDp এবং screenHeightDp এর পরিবর্তন দ্বারা প্রভাবিত হয়।
  • Display.getSize(Point) Configuration পরিবর্তনের দ্বারা পরোক্ষভাবে প্রভাবিত হয়। এপিআই লেভেল 30 থেকে শুরু করে এটি অবহেলিত ছিল।
  • Display.getMetrics() এপিআই লেভেল 33 থেকে ইতিমধ্যেই এভাবে কাজ করেছে।

elegantTextHeight অ্যাট্রিবিউট ডিফল্টে সত্য

অ্যান্ড্রয়েড 15 (API স্তর 35) লক্ষ্য করা অ্যাপগুলির জন্য, elegantTextHeight TextView বৈশিষ্ট্যটি ডিফল্টরূপে true হয়ে যায়, ডিফল্টরূপে ব্যবহৃত কমপ্যাক্ট ফন্টটিকে এমন কিছু স্ক্রিপ্টের সাথে প্রতিস্থাপন করে যেখানে বড় উল্লম্ব মেট্রিক্স রয়েছে যা অনেক বেশি পাঠযোগ্য। বিন্যাস ভাঙা প্রতিরোধ করার জন্য কমপ্যাক্ট ফন্ট চালু করা হয়েছিল; অ্যান্ড্রয়েড 13 (এপিআই লেভেল 33) fallbackLineSpacing অ্যাট্রিবিউট ব্যবহার করে টেক্সট লেআউটকে উল্লম্ব উচ্চতা প্রসারিত করার অনুমতি দিয়ে এই ধরনের অনেক ভাঙন প্রতিরোধ করে।

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

অ্যান্ড্রয়েড 14 (এপিআই লেভেল 34) এবং তার নিচের অ্যাপ্লিকেশানগুলির জন্য elegantTextHeight আচরণ।
অ্যান্ড্রয়েড 15 টার্গেট করা অ্যাপগুলির জন্য elegantTextHeight আচরণ।

জটিল অক্ষর আকারের জন্য TextView প্রস্থ পরিবর্তন

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

যেহেতু এই পরিবর্তনটি একটি TextView কিভাবে প্রস্থ নির্ধারণ করে তা প্রভাবিত করে, তাই যদি অ্যাপটি Android 15 (API লেভেল 35) বা তার বেশি লক্ষ্য করে তাহলে TextView ডিফল্টভাবে আরও প্রস্থ বরাদ্দ করে। আপনি TextView এ setUseBoundsForWidth API-কে কল করে এই আচরণটি সক্ষম বা অক্ষম করতে পারেন।

যেহেতু বাম প্যাডিং যোগ করার ফলে বিদ্যমান লেআউটগুলির জন্য একটি মিসলাইনমেন্ট হতে পারে, প্যাডিংটি ডিফল্টরূপে যোগ করা হয় না এমনকি Android 15 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলির জন্যও। যাইহোক, আপনি setShiftDrawingOffsetForStartOverhang এ কল করে ক্লিপিং প্রতিরোধে অতিরিক্ত প্যাডিং যোগ করতে পারেন।

নিম্নলিখিত উদাহরণগুলি দেখায় কিভাবে এই পরিবর্তনগুলি কিছু ফন্ট এবং ভাষার জন্য পাঠ্য বিন্যাস উন্নত করতে পারে৷

একটি অভিশাপ ফন্টে ইংরেজি পাঠ্যের জন্য আদর্শ বিন্যাস। কিছু চিঠি ক্লিপ করা হয়েছে। এখানে সংশ্লিষ্ট XML হল: 

<TextView
    android:fontFamily="cursive"
    android:text="java" />
অতিরিক্ত প্রস্থ এবং প্যাডিং সহ একই ইংরেজি পাঠ্যের জন্য বিন্যাস। এখানে সংশ্লিষ্ট XML হল: 

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
থাই পাঠ্যের জন্য আদর্শ বিন্যাস। কিছু চিঠি ক্লিপ করা হয়েছে। এখানে সংশ্লিষ্ট XML হল: 

<TextView
    android:text="คอมพิวเตอร์" />
অতিরিক্ত প্রস্থ এবং প্যাডিং সহ একই থাই পাঠ্যের জন্য লেআউট। এখানে সংশ্লিষ্ট XML হল: 

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

EditText-এর জন্য স্থানীয়-সচেতন ডিফল্ট লাইন উচ্চতা

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

EditText উপাদানের প্রতিনিধিত্বকারী তিনটি বাক্স যা ইংরেজি (en), জাপানি (ja), এবং বার্মিজ (my) থেকে পাঠ্য ধারণ করতে পারে। EditText এর উচ্চতা একই, যদিও এই ভাষাগুলির একে অপরের থেকে আলাদা লাইন উচ্চতা রয়েছে।

Android 15 (API লেভেল 35) লক্ষ্য করা অ্যাপগুলির জন্য, একটি ন্যূনতম লাইন উচ্চতা এখন EditText এর জন্য নির্দিষ্ট লোকেলের রেফারেন্স ফন্টের সাথে মেলে, যা নিম্নলিখিত ছবিতে দেখানো হয়েছে:

EditText উপাদানের প্রতিনিধিত্বকারী তিনটি বাক্স যা ইংরেজি (en), জাপানি (ja), এবং বার্মিজ (my) থেকে পাঠ্য ধারণ করতে পারে। EditText এর উচ্চতায় এখন এই ভাষার ফন্টগুলির জন্য ডিফল্ট লাইনের উচ্চতা মিটমাট করার জন্য স্থান রয়েছে।

প্রয়োজনে, আপনার অ্যাপ useLocalePreferredLineHeightForMinimum অ্যাট্রিবিউটটি false নির্দিষ্ট করে পূর্ববর্তী আচরণ পুনরুদ্ধার করতে পারে এবং আপনার অ্যাপটি Kotlin এবং Java এ setMinimumFontMetrics API ব্যবহার করে কাস্টম ন্যূনতম উল্লম্ব মেট্রিক্স সেট করতে পারে।

ক্যামেরা এবং মিডিয়া

Android 15 অ্যানড্রয়েড 15 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলির জন্য ক্যামেরা এবং মিডিয়া আচরণে নিম্নলিখিত পরিবর্তনগুলি করে৷

অডিও ফোকাস অনুরোধের উপর সীমাবদ্ধতা

যে অ্যাপগুলি Android 15 (API স্তর 35) টার্গেট করে সেগুলিকে অবশ্যই শীর্ষ অ্যাপ হতে হবে বা অডিও ফোকাসের অনুরোধ করার জন্য একটি ফোরগ্রাউন্ড পরিষেবা চালাতে হবে৷ যদি কোনো অ্যাপ ফোকাসের অনুরোধ করার চেষ্টা করে যখন এটি এই প্রয়োজনীয়তার একটি পূরণ না করে, তাহলে কলটি AUDIOFOCUS_REQUEST_FAILED ফেরত দেয়।

আপনি অডিও ফোকাস পরিচালনা অডিও ফোকাস সম্পর্কে আরও জানতে পারেন।

নন-SDK সীমাবদ্ধতা আপডেট করা হয়েছে

Android 15 包含更新后的受限非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 15 为目标平台，其中一些变更可能不会立即对您产生影响。不过，尽管您的应用可能会根据应用的目标 API 级别访问某些非 SDK 接口，但只要您使用任何非 SDK 方法或字段，终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以测试该应用，进行确认。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。不过，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，则应请求新的公共 API。

অ্যান্ড্রয়েডের এই প্রকাশের পরিবর্তনগুলি সম্পর্কে আরও জানতে, Android 15-এ নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেটগুলি দেখুন। সাধারণত নন-SDK ইন্টারফেস সম্পর্কে আরও জানতে, নন-SDK ইন্টারফেসের উপর সীমাবদ্ধতা দেখুন।