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

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

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

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

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

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

mediaProcessing পরিষেবার ধরন সম্পর্কে আরও তথ্যের জন্য, Android 15: মিডিয়া প্রসেসিং-এর জন্য অগ্রভাগের পরিষেবার প্রকারগুলিতে পরিবর্তনগুলি দেখুন৷

টেস্টিং

আপনার অ্যাপের আচরণ পরীক্ষা করার জন্য, আপনি মিডিয়া প্রসেসিং টাইমআউট সক্ষম করতে পারেন এমনকি যদি আপনার অ্যাপ অ্যান্ড্রয়েড 15 টার্গেট না করে (যতক্ষণ অ্যাপটি অ্যান্ড্রয়েড 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 সর্বশেষ 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গুলি Android 15 (API স্তর 35) এ চালু করা হয়েছে, তাই Kotlin কম্পাইলার ফাংশন কলগুলি সমাধান করে, উদাহরণস্বরূপ list.removeFirst() , kotlin-stdlib এ এক্সটেনশন ফাংশনগুলির পরিবর্তে নতুন List APIগুলিতে স্থিরভাবে।

    যদি একটি অ্যাপ পুনরায় কম্পাইল করা হয় 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-এ এমন পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে যা অ্যাপ এবং ব্যবহারকারীদের ক্ষতিকারক অ্যাপ থেকে রক্ষা করতে সিস্টেম নিরাপত্তার প্রচার করে।

সীমাবদ্ধ TLS সংস্করণ

Android 15 限制了对 TLS 版本 1.0 和 1.1 的使用。这些版本之前已在 Android 中被弃用，但现在不允许面向 Android 15 的应用使用。

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

অ্যান্ড্রয়েড 15 ব্যবহারকারীদের ক্ষতিকারক অ্যাপ থেকে রক্ষা করে এবং ক্ষতিকারক ব্যাকগ্রাউন্ড অ্যাপগুলিকে অন্য অ্যাপগুলিকে অগ্রভাগে আনতে, তাদের বিশেষাধিকারগুলিকে উন্নত করতে এবং ব্যবহারকারীর ইন্টারঅ্যাকশনের অপব্যবহার করে এমন পরিবর্তনগুলি যোগ করে তাদের ডিভাইসের উপর আরও নিয়ন্ত্রণ দেয়। Android 10 (API স্তর 29) থেকে পটভূমি কার্যকলাপ লঞ্চ সীমাবদ্ধ করা হয়েছে।

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

UID মিলের জন্য সীমাবদ্ধতা ছাড়াও, এই অন্যান্য পরিবর্তনগুলিও অন্তর্ভুক্ত:

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

অ্যান্ড্রয়েড 15 ব্যবহারকারীদের ক্ষতিকারক অ্যাপ থেকে রক্ষা করে এবং ক্ষতিকারক ব্যাকগ্রাউন্ড অ্যাপগুলিকে অন্য অ্যাপগুলিকে অগ্রভাগে আনতে, তাদের বিশেষাধিকারগুলিকে উন্নত করতে এবং ব্যবহারকারীর ইন্টারঅ্যাকশনের অপব্যবহার করে এমন পরিবর্তনগুলি যোগ করে তাদের ডিভাইসের উপর আরও নিয়ন্ত্রণ দেয়। Android 10 (API স্তর 29) থেকে পটভূমি কার্যকলাপ লঞ্চ সীমাবদ্ধ করা হয়েছে।

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

UID মিলের জন্য সীমাবদ্ধতা ছাড়াও, এই অন্যান্য পরিবর্তনগুলিও অন্তর্ভুক্ত:

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

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

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

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

আপনার অ্যাপ এই পরিবর্তনগুলিতে কীভাবে সাড়া দেয় তা পরীক্ষা করার জন্য, আপনার অ্যাপে StrictMode ব্যবহার করুন। Intent ব্যবহার লঙ্ঘন সম্পর্কে বিস্তারিত লগ দেখতে, নিম্নলিখিত পদ্ধতি যোগ করুন:

কোটলিন 

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

জাভা 

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

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

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

আপনার অ্যাপ এই পরিবর্তনগুলিতে কীভাবে সাড়া দেয় তা পরীক্ষা করার জন্য, আপনার অ্যাপে StrictMode ব্যবহার করুন। Intent ব্যবহার লঙ্ঘন সম্পর্কে বিস্তারিত লগ দেখতে, নিম্নলিখিত পদ্ধতি যোগ করুন:

কোটলিন 

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

জাভা 

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 设备上实现全屏显示的应用。
此应用主要使用会自动应用边衬区的 Material 3 Compose 组件。此屏幕不受 Android 15 强制执行的无边框措施的负面影响。

这是一项重大变更，可能会对应用的界面产生负面影响。这些更改会影响以下界面区域：

  • 手势柄导航栏
    • 默认透明。
    • 底部偏移量处于停用状态，因此内容会绘制在系统导航栏后面，除非应用了边衬区。
    • setNavigationBarColor 和 R.attr#navigationBarColor 已被弃用，不会影响手势导航。
    • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 继续对使用手势进行导航没有任何影响。
  • “三按钮”导航
    • 默认情况下，不透明度设置为 80%，颜色可能与窗口背景颜色一致。
    • 底部偏移量处于停用状态，因此内容会绘制在系统导航栏后面，除非应用了边衬区。
    • 默认情况下，setNavigationBarColor 和 R.attr#navigationBarColor 设置为与窗口背景相匹配。窗口背景必须是颜色可绘制对象，才能应用此默认值。此 API 已弃用，但仍会影响三按钮导航。
    • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 默认情况下为 true，这会在三按钮导航栏中添加 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 上可能会显示不同的内容。

以 Android 14 为目标平台且在 Android 15 设备上不是全屏显示的应用。
以 Android 15（API 级别 35）为目标平台且在 Android 15 设备上实现全屏显示的应用。不过，由于 Android 15 边缘到边缘的强制执行，许多元素现在会被状态栏、三按钮导航栏或刘海屏遮挡。隐藏界面包括 Material 2 顶部应用栏、悬浮操作按钮和列表项。
以 Android 15（API 级别 35）为目标平台的应用在 Android 15 设备上处于全屏显示状态，并应用边衬区，以便界面不会被隐藏。
如果应用已实现全屏显示，需要检查哪些方面

如果您的应用已实现全屏显示并应用边衬区，则除了以下情形外，您基本上不会受到影响。不过，即使您认为自己不受影响，我们仍建议您测试应用。

  • 您有一个非浮动窗口，例如使用 SHORT_EDGES、NEVER 或 DEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS 的 Activity。如果您的应用在启动时崩溃，这可能是由启动画面引起的。您可以将核心启动画面依赖项升级到 1.2.0-alpha01 或更高版本，也可以设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
  • 可能存在流量较低且界面被遮挡的屏幕。验证这些访问频率较低的界面是否没有被遮挡的界面。低流量界面包括：
    • 初始配置或登录界面
    • “设置”页面
如果您的应用尚未实现全屏显示，需要检查哪些方面

如果您的应用尚未实现全屏显示，则很可能会受到影响。除了已经实现全屏显示的 app 的场景之外，您还应考虑以下事项：

  • 如果您的应用在 Compose 中使用 Material 3 组件 (androidx.compose.material3)，例如 TopAppBar、BottomAppBar 和 NavigationBar，这些组件很可能不会受到影响，因为它们会自动处理边衬区。
  • 如果您的应用使用的是 Compose 中的 Material 2 组件 (androidx.compose.material)，这些组件不会自动处理边衬区。不过，您可以获得边衬区的访问权限，然后手动应用边衬区。在 androidx.compose.material 1.6.0 及更高版本中，使用 windowInsets 参数可为 BottomAppBar、TopAppBar、BottomNavigation 和 NavigationRail 手动应用边衬区。 同样，请为 Scaffold 使用 contentWindowInsets 参数。
  • 如果您的应用使用视图和 Material 组件 (com.google.android.material)，则大多数基于视图的 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 将可组合项或视图放置在系统栏后面，以获取三按钮导航栏高度。

其他全屏显示资源

如需了解有关应用边衬区的其他注意事项，请参阅全屏视图和全屏 Compose 指南。

已弃用的 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 অ্যাট্রিবিউট ডিফল্টে সত্য

对于以 Android 15（API 级别 35）为目标平台的应用，elegantTextHeight TextView 属性默认会变为 true，将默认使用的紧凑字体替换为一些具有较大垂直测量的脚本，使其更易于阅读。紧凑字体旨在防止布局中断；Android 13（API 级别 33）允许文本布局利用 fallbackLineSpacing 属性拉伸垂直高度，从而防止许多此类中断。

在 Android 15 中，系统中仍保留了紧凑字体，因此您的应用可以将 elegantTextHeight 设置为 false 以获得与之前相同的行为，但即将发布的版本不太可能支持此字体。因此，如果您的应用支持以下脚本：阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语，请将 elegantTextHeight 设置为 true 以测试您的应用。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用的 elegantTextHeight 行为。
以 Android 15 为目标平台的应用的 elegantTextHeight 行为。

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

在以前的 Android 版本中，某些具有复杂形状的手写字体或语言可能会在上一个或下一个字符的区域绘制字母。在某些情况下，此类字母会在开头或结尾处被剪裁。从 Android 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-এ Android বিকাশকারীদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। যখনই সম্ভব, আমরা নিশ্চিত করি যে আমরা নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে।

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

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

如需详细了解此 Android 版本中的变更，请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息，请参阅对非 SDK 接口的限制。