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

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

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

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

অ্যান্ড্রয়েড ১৫ অ্যান্ড্রয়েড সিস্টেমের বিভিন্ন মূল ক্ষমতা পরিবর্তন বা প্রসারিত করে।

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

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

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

Android 15 Android 15 (API স্তর 35) বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলির জন্য dataSync একটি নতুন টাইমআউট আচরণ প্রবর্তন করে৷ এই আচরণটি নতুন mediaProcessing ফোরগ্রাউন্ড পরিষেবা প্রকারের ক্ষেত্রেও প্রযোজ্য।

সিস্টেমটি একটি অ্যাপের dataSync পরিষেবাগুলিকে 24-ঘন্টা সময়ের মধ্যে মোট 6 ঘন্টা চালানোর অনুমতি দেয়, তারপরে সিস্টেমটি চলমান পরিষেবাটির Service.onTimeout(int, int) পদ্ধতিতে কল করে (Android 15 এ চালু করা হয়েছে)৷ এই সময়ে, পরিষেবাটিতে Service.stopSelf() কল করার জন্য কয়েক সেকেন্ড সময় আছে। যখন Service.onTimeout() কল করা হয়, তখন পরিষেবাটিকে আর অগ্রভাগের পরিষেবা হিসাবে বিবেচনা করা হয় না। যদি পরিষেবাটি Service.stopSelf() কল না করে, তবে সিস্টেমটি একটি অভ্যন্তরীণ ব্যতিক্রম নিক্ষেপ করে৷ ব্যতিক্রমটি নিম্নলিখিত বার্তার সাথে লগক্যাটে লগ ইন করা হয়েছে:

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 ফোরগ্রাউন্ড পরিষেবাগুলি সরাসরি ব্যবহারকারীর ইন্টারঅ্যাকশনের ফলে শুরু করুন; যেহেতু পরিষেবাটি শুরু হওয়ার সময় আপনার অ্যাপটি ফোরগ্রাউন্ডে থাকে, তাই অ্যাপটি ব্যাকগ্রাউন্ডে যাওয়ার পরে আপনার পরিষেবার পুরো ছয় ঘন্টা থাকে।
  4. একটি dataSync ফোরগ্রাউন্ড পরিষেবা ব্যবহার করার পরিবর্তে, একটি বিকল্প API ব্যবহার করুন৷

যদি আপনার অ্যাপের dataSync ফোরগ্রাউন্ড পরিষেবাগুলি গত 24-এর মধ্যে 6 ঘন্টা ধরে চলে থাকে, তবে ব্যবহারকারী আপনার অ্যাপটিকে ফোরগ্রাউন্ডে না আনলে আপনি অন্য dataSync ফোরগ্রাউন্ড পরিষেবা শুরু করতে পারবেন না (যা টাইমার রিসেট করে)। আপনি যদি অন্য একটি dataSync ফোরগ্রাউন্ড পরিষেবা শুরু করার চেষ্টা করেন, তাহলে সিস্টেমটি "ফোরগ্রাউন্ড সার্ভিস টাইপ ডেটাসিঙ্কের জন্য সময়সীমা ইতিমধ্যেই শেষ" এর মতো একটি ত্রুটি বার্তা সহ ForegroundServiceStartNotAllowedException ছুড়ে দেয়৷

টেস্টিং

আপনার অ্যাপের আচরণ পরীক্ষা করার জন্য, আপনি ডেটা সিঙ্ক টাইমআউট সক্ষম করতে পারেন এমনকি যদি আপনার অ্যাপ অ্যান্ড্রয়েড 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 (API লেভেল 35) এবং উচ্চতরকে টার্গেট করে তারা আর কোনও ডিভাইসে গ্লোবাল স্টেট বা Do Not Disturb (DND) এর নীতি পরিবর্তন করতে পারে না (হয় ব্যবহারকারী সেটিংস পরিবর্তন করে বা DND মোড বন্ধ করে)। পরিবর্তে, অ্যাপগুলিকে অবশ্যই একটি AutomaticZenRule অবদান রাখতে হবে, যা সিস্টেমটি বিদ্যমান সর্বাধিক-নিষেধমূলক-নীতি-জয় স্কিমের সাথে একটি বৈশ্বিক নীতিতে একত্রিত করে। বিদ্যমান API-এ কল যা পূর্বে গ্লোবাল স্টেটকে প্রভাবিত করেছিল ( setInterruptionFilter , setNotificationPolicy ) এর ফলে একটি অন্তর্নিহিত AutomaticZenRule তৈরি বা আপডেট হয়, যা সেই API কলগুলির কল-চক্রের উপর নির্ভর করে টগল করা এবং বন্ধ করা হয়।

মনে রাখবেন যে এই পরিবর্তনটি শুধুমাত্র পর্যবেক্ষণযোগ্য আচরণকে প্রভাবিত করে যদি অ্যাপটি setInterruptionFilter(INTERRUPTION_FILTER_ALL) কল করে এবং আশা করে যে কলটি একটি AutomaticZenRule নিষ্ক্রিয় করবে যা আগে তাদের মালিকদের দ্বারা সক্রিয় করা হয়েছিল৷

OpenJDK API পরিবর্তন

অ্যান্ড্রয়েড ১৫ সর্বশেষ ওপেনজেডিকে এলটিএস রিলিজের বৈশিষ্ট্যগুলির সাথে সামঞ্জস্যপূর্ণ করার জন্য অ্যান্ড্রয়েডের মূল লাইব্রেরিগুলিকে রিফ্রেশ করার কাজ চালিয়ে যাচ্ছে।

এই পরিবর্তনগুলির মধ্যে কিছু 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() এর সাথে মিলবে বলে আশা করা উচিত নয়।

অ্যান্ড্রয়েড ১৫ (এপিআই লেভেল ৩৫) ব্যবহার করার জন্য আপনার অ্যাপের বিল্ড কনফিগারেশনে compileSdk আপডেট করার পরে নতুন SequencedCollection API আপনার অ্যাপের সামঞ্জস্যকে প্রভাবিত করতে পারে:

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

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

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

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

    অ্যান্ড্রয়েড গ্রেডল প্লাগইনের বিদ্যমান NewApi লিন্ট বিকল্পটি এই নতুন এপিআই ব্যবহারগুলি ধরতে পারে।

    ./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 কম্পাইলার একটি বিল্ড-টাইম ত্রুটি আউটপুট করে। উদাহরণস্বরূপ:

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

    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

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

    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

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

    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();
}

নিরাপত্তা

অ্যান্ড্রয়েড ১৫-এ এমন পরিবর্তন অন্তর্ভুক্ত রয়েছে যা সিস্টেম সুরক্ষাকে উৎসাহিত করে এবং অ্যাপ এবং ব্যবহারকারীদের ক্ষতিকারক অ্যাপ থেকে রক্ষা করতে সাহায্য করে।

সীমাবদ্ধ TLS ভার্সন

Android 15 TLS সংস্করণ 1.0 এবং 1.1 ব্যবহার সীমাবদ্ধ করে। এই সংস্করণগুলি পূর্বে অ্যান্ড্রয়েডে অবহেলিত ছিল, কিন্তু এখন Android 15 টার্গেট করা অ্যাপগুলির জন্য অননুমোদিত।

সুরক্ষিত ব্যাকগ্রাউন্ড অ্যাক্টিভিটি লঞ্চ করা হচ্ছে

অ্যান্ড্রয়েড ১৫ ব্যবহারকারীদের ক্ষতিকারক অ্যাপ থেকে রক্ষা করে এবং তাদের ডিভাইসের উপর আরও নিয়ন্ত্রণ দেয়, এমন পরিবর্তন যোগ করে যা ক্ষতিকারক ব্যাকগ্রাউন্ড অ্যাপগুলিকে অন্যান্য অ্যাপগুলিকে সামনে আনা, তাদের সুবিধাগুলি উন্নত করা এবং ব্যবহারকারীর ইন্টারঅ্যাকশনের অপব্যবহার করা থেকে বিরত রাখে। অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) থেকে ব্যাকগ্রাউন্ড অ্যাক্টিভিটি লঞ্চ সীমিত করা হয়েছে।

অন্যান্য পরিবর্তন

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

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

অ্যান্ড্রয়েড ১৫ ইনটেন্টের জন্য StrictMode চালু করেছে।

Intent ব্যবহারের লঙ্ঘন সম্পর্কে বিস্তারিত লগ দেখতে, নিম্নলিখিত পদ্ধতিটি ব্যবহার করুন:

কোটলিন 

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

জাভা 

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

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

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

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

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

প্রান্ত থেকে প্রান্ত প্রয়োগ

যদি অ্যাপটি অ্যান্ড্রয়েড ১৫ (এপিআই লেভেল ৩৫) টার্গেট করে থাকে, তাহলে অ্যান্ড্রয়েড ১৫ চালিত ডিভাইসগুলিতে অ্যাপগুলি ডিফল্টভাবে এজ-টু-এজ থাকে।

এমন একটি অ্যাপ যা অ্যান্ড্রয়েড ১৪-কে লক্ষ্য করে এবং অ্যান্ড্রয়েড ১৫ ডিভাইসে এটি এজ-টু-এজ নয়।


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

এটি একটি অসাধারণ পরিবর্তন যা আপনার অ্যাপের UI-তে নেতিবাচক প্রভাব ফেলতে পারে। পরিবর্তনগুলি নিম্নলিখিত UI ক্ষেত্রগুলিকে প্রভাবিত করে:

  • অঙ্গভঙ্গি হ্যান্ডেল নেভিগেশন বার
    • ডিফল্টরূপে স্বচ্ছ।
    • নীচের অফসেটটি অক্ষম করা হয়েছে তাই ইনসেট প্রয়োগ না করা পর্যন্ত বিষয়বস্তু সিস্টেম নেভিগেশন বারের পিছনে চলে যায়।
    • setNavigationBarColor এবং R.attr#navigationBarColor অবচিত এবং অঙ্গভঙ্গি নেভিগেশনকে প্রভাবিত করে না।
    • setNavigationBarContrastEnforced এবং R.attr#navigationBarContrastEnforced জেসচার নেভিগেশনের উপর কোনও প্রভাব ফেলবে না।
  • ৩-বোতাম নেভিগেশন
    • ডিফল্টরূপে অস্বচ্ছতা ৮০% এ সেট করা আছে, রঙ সম্ভবত উইন্ডোর পটভূমির সাথে মিলে যাবে।
    • ইনসেট প্রয়োগ না করা হলে, নীচের অফসেটটি অক্ষম করা হয়েছে যাতে কন্টেন্ট সিস্টেম নেভিগেশন বারের পিছনে চলে যায়।
    • 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 Auto তে ভিন্নভাবে প্রদর্শিত হতে পারে।

এমন একটি অ্যাপ যা অ্যান্ড্রয়েড ১৪-কে লক্ষ্য করে এবং অ্যান্ড্রয়েড ১৫ ডিভাইসে এটি এজ-টু-এজ নয়।
একটি অ্যাপ যা অ্যান্ড্রয়েড ১৫ (এপিআই লেভেল ৩৫) কে টার্গেট করে এবং অ্যান্ড্রয়েড ১৫ ডিভাইসে এটি এজ-টু-এজ। তবে, অ্যান্ড্রয়েড ১৫ এজ-টু-এজ এনফোর্সমেন্টের কারণে অনেক উপাদান এখন স্ট্যাটাস বার, ৩-বোতাম নেভিগেশন বার বা ডিসপ্লে কাটআউট দ্বারা লুকানো থাকে। লুকানো 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 Components ( androidx.compose.material3 ) ব্যবহার করে, যেমন TopAppBar , BottomAppBar , এবং NavigationBar , তাহলে এই কম্পোনেন্টগুলি সম্ভবত প্রভাবিত হবে না কারণ তারা স্বয়ংক্রিয়ভাবে ইনসেটগুলি পরিচালনা করে।
  • যদি আপনার অ্যাপটি Compose-এ Material 2 Components ( 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" যোগ করুন।
আপনার অ্যাপটি কাস্টম ব্যাকগ্রাউন্ড সুরক্ষা প্রদান করবে কিনা তা কী পরীক্ষা করবেন

যদি আপনার অ্যাপটিকে ৩-বোতাম নেভিগেশন বা স্ট্যাটাস বারে কাস্টম ব্যাকগ্রাউন্ড সুরক্ষা প্রদান করতে হয়, তাহলে আপনার অ্যাপটিকে ৩-বোতাম নেভিগেশন বারের উচ্চতা পেতে 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 ব্যবহারকে আরও উপযুক্ত কিছু দিয়ে প্রতিস্থাপন করা উচিত।

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

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

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

elegantTextHeight অ্যাট্রিবিউট ডিফল্টভাবে true এ সেট করা হয়

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

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

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

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

অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে, কিছু অভিশাপযুক্ত ফন্ট বা ভাষা যা জটিল আকার ধারণ করে সেগুলি পূর্ববর্তী বা পরবর্তী অক্ষরের ক্ষেত্রে অক্ষরগুলি আঁকতে পারে। কিছু ক্ষেত্রে, এই জাতীয় অক্ষরগুলি শুরুতে বা শেষের অবস্থানে ক্লিপ করা হয়েছিল। অ্যান্ড্রয়েড 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 (API স্তর 35) টার্গেট করে সেগুলিকে অবশ্যই শীর্ষ অ্যাপ হতে হবে বা অডিও ফোকাসের অনুরোধ করার জন্য একটি ফোরগ্রাউন্ড পরিষেবা চালাতে হবে৷ যদি কোনো অ্যাপ ফোকাসের অনুরোধ করার চেষ্টা করে যখন এটি এই প্রয়োজনীয়তার একটি পূরণ না করে, তাহলে কলটি AUDIOFOCUS_REQUEST_FAILED ফেরত দেয়।

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

আপডেট করা নন-SDK বিধিনিষেধ

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

যদি আপনার অ্যাপটি Android 15-কে টার্গেট না করে, তাহলে এই পরিবর্তনগুলির কিছু তাৎক্ষণিকভাবে আপনার উপর প্রভাব ফেলতে পারে না। তবে, আপনার অ্যাপের টার্গেট API স্তরের উপর নির্ভর করে কিছু নন-SDK ইন্টারফেস অ্যাক্সেস করা সম্ভব হলেও, যেকোনো নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে আপনার অ্যাপটি ভেঙে যাওয়ার ঝুঁকি সবসময় বেশি থাকে।

যদি আপনার অ্যাপটি নন-SDK ইন্টারফেস ব্যবহার করে কিনা তা নিশ্চিত না হন, তাহলে আপনি আপনার অ্যাপটি পরীক্ষা করে দেখতে পারেন। যদি আপনার অ্যাপটি নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে মাইগ্রেশনের পরিকল্পনা শুরু করা উচিত। তবুও, আমরা বুঝতে পারি যে কিছু অ্যাপের নন-SDK ইন্টারফেস ব্যবহারের জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। যদি আপনি আপনার অ্যাপে কোনও বৈশিষ্ট্যের জন্য নন-SDK ইন্টারফেস ব্যবহারের বিকল্প খুঁজে না পান, তাহলে আপনার একটি নতুন পাবলিক API অনুরোধ করা উচিত।

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