আচরণগত পরিবর্তন: Android 15 বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপ

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

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

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

Android 15, Android সিস্টেমের বিভিন্ন মূল ক্ষমতা পরিবর্তন বা প্রসারিত করে।

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

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

• ডেটা সিঙ্ক ফোরগ্রাউন্ড পরিষেবা সময় শেষ আচরণ
• নতুন মিডিয়া প্রক্রিয়াকরণ ফোরগ্রাউন্ড পরিষেবার ধরন
• BOOT_COMPLETED সম্প্রচার রিসিভার ফোরগ্রাউন্ড পরিষেবা চালু করার উপর নিষেধাজ্ঞা
• একটি অ্যাপের SYSTEM_ALERT_WINDOW অনুমতি থাকাকালীন ফোরগ্রাউন্ড পরিষেবাগুলি শুরু করার উপর বিধিনিষেধ

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

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 রিসিভারদের নিম্নলিখিত ধরনের অগ্রভাগের পরিষেবা চালু করার অনুমতি নেই :

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (অ্যান্ড্রয়েড 14 সাল থেকে microphone জন্য এই সীমাবদ্ধতা রয়েছে)

যদি একটি 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-তে পরিবর্তন

লেটেস্ট OpenJDK LTS রিলিজে থাকা ফিচারের সাথে সামঞ্জস্য বজায় রাখতে, Android 15-এ Android-এর কোর লাইব্রেরি রিফ্রেশ করার কাজ চালিয়ে যাওয়া হচ্ছে।

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

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

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  যেমন, আর্গুমেন্ট ইন্ডেক্স 0 ব্যবহার করা হলে (ফর্ম্যাট স্ট্রিংয়ে %0) নিম্নলিখিত ব্যতিক্রমটি থ্রো করা হয়:

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  এই ক্ষেত্রে, ১ (%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(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

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

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

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

  Java-তে List টাইপ Kotlin-এ MutableList টাইপে ম্যাপ করা হয়। Android ১৫ (API লেভেল ৩৫)-এ List.removeFirst() এবং List.removeLast() API রিলিজ করা হয়েছে, তাই 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 প্লাগ-ইনে আগে থেকে থাকা NewApi লিন্ট বিকল্প এইসব নতুন 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' } সরানোর কথা বিবেচনা করুন।

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

  আগে থেকে থাকা টাইপে নতুন পদ্ধতি যোগ করা হয়েছে, যেমন, 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();
  }
  

নিরাপত্তা

Android 15-এ এমন কিছু পরিবর্তন করা হয়েছে যা সিস্টেমের নিরাপত্তা উন্নত করে এবং ক্ষতিকর অ্যাপ থেকে অ্যাপ ও ব্যবহারকারীদের সুরক্ষিত রাখতে সাহায্য করে।

বিধিনিষেধযুক্ত 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

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

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

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

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

Android 15 (API লেভেল 35) টার্গেট করা অ্যাপ Android 15-এ চলা ডিভাইসে ডিফল্ট হিসেবে এজ-টু-এজ হয়।

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

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

আপনার অ্যাপ আগে থেকেই এজ-টু-এজ হলে কী চেক করতে হবে

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

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

আপনার অ্যাপ আগে থেকেই এজ-টু-এজ না হলে কী চেক করতে হবে

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

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

আপনার অ্যাপকে কাস্টম ব্যাকগ্রাউন্ড সুরক্ষা প্রদান করতে হলে কী কী চেক করতে হবে

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

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

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

বাতিল করা API

নিম্নলিখিত API-গুলি অননুমোদিত কিন্তু বন্ধ করা হয়নি:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor (৩টি বোতাম দিয়ে করা নেভিগেশনের জন্য, ৮০% আলফা সহ)
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor (৩টি বোতাম দিয়ে করা নেভিগেশনের জন্য, ৮০% আলফা সহ)
• Window#setStatusBarContrastEnforced

নিম্নলিখিত API বন্ধ ও বাতিল করা হয়েছে:

• R.attr#navigationBarColor (জেসচার নেভিগেশনের জন্য)
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor (জেসচার নেভিগেশনের জন্য)
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

স্থিতিশীল কনফিগারেশন

আপনার অ্যাপ 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 সাইজ আর সিস্টেম বার বাদ দেয় না।
• screenWidthDp ও screenHeightDp-এ করা পরিবর্তনের ফলে Configuration.smallestScreenWidthDp পরোক্ষভাবে প্রভাবিত হয়েছে।
• Configuration.orientation-এ পরোক্ষভাবে প্রভাবিত হয় screenWidthDp এবং screenHeightDp-এ পরিবর্তন করার ফলে, যা প্রায়-বর্গাকার ডিভাইসে দেখা যায়।
• Configuration-এ করা পরিবর্তনের ফলে Display.getSize(Point) পরোক্ষভাবে প্রভাবিত হয়েছে। API লেভেল ৩০ থেকে এটি বন্ধ করা হয়েছে।
• API লেভেল ৩৩ থেকে Display.getMetrics() আগে থেকেই এইভাবে কাজ করেছে।

elegantTextHeight অ্যাট্রিবিউট ডিফল্ট হিসেবে true-তে সেট করা থাকে

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

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

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

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

ক্যামেরা ও মিডিয়া

Android 15 বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করে এমন অ্যাপের জন্য Android 15 ক্যামেরা ও মিডিয়া আচরণে নিম্নলিখিত পরিবর্তন করে।

অডিও ফোকাসের জন্য অনুরোধ করার ক্ষেত্রে বিধিনিষেধ

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

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

SDK নয় এমন বিধিনিষেধ আপডেট করা হয়েছে

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

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

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

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