আচরণ পরিবর্তন: সমস্ত অ্যাপ্লিকেশন

Android 14 প্ল্যাটফর্মে এমন আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণগত পরিবর্তনগুলি সমস্ত অ্যাপের ক্ষেত্রে প্রযোজ্য যখন তারা Android 14 এ চলে, targetSdkVersion নির্বিশেষে। আপনার অ্যাপটি পরীক্ষা করা উচিত এবং তারপরে প্রযোজ্য ক্ষেত্রে এগুলি সঠিকভাবে সমর্থন করার জন্য প্রয়োজন অনুসারে এটি পরিবর্তন করা উচিত।

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

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

ডিফল্টরূপে সঠিক অ্যালার্মের সময়সূচী বাতিল করা হয়

Exact alarms are meant for user-intentioned notifications, or for actions that need to happen at a precise time. Starting in Android 14, the SCHEDULE_EXACT_ALARM permission is no longer being pre-granted to most newly installed apps targeting Android 13 and higher—the permission is denied by default.

Learn more about the changes to the permission for scheduling exact alarms.

অ্যাপ ক্যাশে করার সময় প্রসঙ্গ-নিবন্ধিত সম্প্রচারগুলি সারিবদ্ধ থাকে

Android 14-এ, অ্যাপটি ক্যাশে থাকা অবস্থায় সিস্টেমটি প্রসঙ্গ-নিবন্ধিত সম্প্রচারগুলিকে একটি সারিতে রাখতে পারে৷ এটি অ্যাসিঙ্ক বাইন্ডার লেনদেনের জন্য Android 12 (API স্তর 31) চালু করা সারিবদ্ধ আচরণের অনুরূপ। ম্যানিফেস্ট-ঘোষিত সম্প্রচারগুলি সারিবদ্ধ নয় এবং সম্প্রচার বিতরণের জন্য অ্যাপগুলিকে ক্যাশে করা অবস্থা থেকে সরানো হয়৷

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

অ্যাপগুলি কেবল তাদের নিজস্ব ব্যাকগ্রাউন্ড প্রক্রিয়াগুলিকেই ধ্বংস করতে পারে

অ্যান্ড্রয়েড 14 থেকে শুরু করে, যখন আপনার অ্যাপ killBackgroundProcesses() কল করে, তখন API শুধুমাত্র আপনার নিজের অ্যাপের ব্যাকগ্রাউন্ড প্রসেসগুলিকে মেরে ফেলতে পারে।

আপনি যদি অন্য অ্যাপের প্যাকেজ নামে পাস করেন, এই পদ্ধতিটি সেই অ্যাপের ব্যাকগ্রাউন্ড প্রসেসগুলিতে কোনও প্রভাব ফেলবে না এবং নিম্নলিখিত বার্তাটি Logcat-এ উপস্থিত হবে:

Invalid packageName: com.example.anotherapp

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

প্রথম GATT ক্লায়েন্টের জন্য MTU 517 এ সেট করা হয়েছে যেটি MTU অনুরোধ করছে।

অ্যান্ড্রয়েড 14 থেকে শুরু করে, অ্যান্ড্রয়েড ব্লুটুথ স্ট্যাকটি ব্লুটুথ কোর স্পেসিফিকেশনের সংস্করণ 5.2কে আরও কঠোরভাবে মেনে চলে এবং যখন প্রথম GATT ক্লায়েন্ট BluetoothGatt#requestMtu(int) API ব্যবহার করে একটি MTU অনুরোধ করে তখন BLE ATT MTU-কে 517 বাইটে অনুরোধ করে এবং সমস্ত কিছু উপেক্ষা করে। সেই ACL সংযোগে পরবর্তী MTU অনুরোধ।

এই পরিবর্তনটি মোকাবেলা করতে এবং আপনার অ্যাপকে আরও শক্তিশালী করতে, নিম্নলিখিত বিকল্পগুলি বিবেচনা করুন:

• আপনার পেরিফেরাল ডিভাইসটি অ্যান্ড্রয়েড ডিভাইসের এমটিইউ অনুরোধে একটি যুক্তিসঙ্গত মান সহ সাড়া দেবে যা পেরিফেরাল দ্বারা মিটমাট করা যেতে পারে। চূড়ান্ত আলোচনার মানটি হবে ন্যূনতম Android অনুরোধ করা মান এবং দূরবর্তী প্রদত্ত মান (উদাহরণস্বরূপ, min(517, remoteMtu) )
  • এই ফিক্সটি বাস্তবায়নের জন্য পেরিফেরালের জন্য একটি ফার্মওয়্যার আপডেটের প্রয়োজন হতে পারে
• বিকল্পভাবে, আপনার পেরিফেরালের পরিচিত সমর্থিত মান এবং প্রাপ্ত MTU পরিবর্তনের মধ্যে ন্যূনতমের উপর ভিত্তি করে আপনার GATT বৈশিষ্ট্যের লেখাগুলিকে সীমাবদ্ধ করুন
  • একটি অনুস্মারক যে আপনাকে হেডারগুলির জন্য সমর্থিত আকার থেকে 5 বাইট কমাতে হবে
  • যেমন: arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

একটি অ্যাপকে সীমাবদ্ধ স্ট্যান্ডবাই বাকেটে রাখার নতুন কারণ

Android 14 একটি অ্যাপকে সীমাবদ্ধ স্ট্যান্ডবাই বাকেটের মধ্যে স্থাপন করার একটি নতুন কারণ উপস্থাপন করেছে৷ onStartJob , onStopJob , বা onBind পদ্ধতির সময়সীমার কারণে অ্যাপের কাজগুলি একাধিকবার ANR ত্রুটিগুলিকে ট্রিগার করে৷ ( onStartJob এবং onStopJob এ পরিবর্তনের জন্য JobScheduler কলব্যাক এবং নেটওয়ার্ক আচরণকে শক্তিশালী করে দেখুন।)

অ্যাপটি সীমাবদ্ধ স্ট্যান্ডবাই বালতিতে প্রবেশ করেছে কিনা তা ট্র্যাক করতে, আমরা কাজ সম্পাদনে API UsageStatsManager.getAppStandbyBucket() অথবা অ্যাপ স্টার্টআপে UsageStatsManager.queryEventsForSelf() দিয়ে লগ করার পরামর্শ দিই।

mlock 64 KB-তে সীমাবদ্ধ

অ্যান্ড্রয়েড 14 (এপিআই লেভেল 34) এবং উচ্চতর, প্ল্যাটফর্মটি সর্বাধিক মেমরি কমিয়ে দেয় যা mlock() ব্যবহার করে লক করা যায় প্রতি প্রক্রিয়ায় 64 KB। পূর্ববর্তী সংস্করণগুলিতে, সীমাটি প্রতি প্রক্রিয়ায় 64 MB ছিল। এই সীমাবদ্ধতাটি অ্যাপ এবং সিস্টেম জুড়ে আরও ভাল মেমরি পরিচালনার প্রচার করে। ডিভাইস জুড়ে আরও ধারাবাহিকতা প্রদান করতে, Android 14 সামঞ্জস্যপূর্ণ ডিভাইসগুলিতে নতুন mlock() সীমার জন্য একটি নতুন CTS পরীক্ষা যোগ করে।

সিস্টেম ক্যাশেড-অ্যাপ রিসোর্স ব্যবহার জোরদার করে

ডিজাইন অনুসারে , একটি অ্যাপের প্রক্রিয়াটি একটি ক্যাশে অবস্থায় থাকে যখন এটিকে ব্যাকগ্রাউন্ডে সরানো হয় এবং অন্য কোনও অ্যাপ প্রক্রিয়া উপাদান চলমান থাকে না। এই ধরনের একটি অ্যাপ প্রক্রিয়া সিস্টেম মেমরি চাপের কারণে নিহত হওয়ার বিষয়। onStop() পদ্ধতি কল করার পরে এবং ফেরত দেওয়ার পরে যে কোনও কাজ যা Activity ইনস্ট্যান্স সঞ্চালন করে, এই অবস্থায়, অবিশ্বস্ত এবং দৃঢ়ভাবে নিরুৎসাহিত করা হয়।

অ্যান্ড্রয়েড 14 এই ডিজাইনে ধারাবাহিকতা এবং প্রয়োগের পরিচয় দেয়। একটি অ্যাপ প্রসেস ক্যাশ করা অবস্থায় প্রবেশ করার কিছুক্ষণ পরে, একটি প্রক্রিয়া উপাদান জীবনচক্রের একটি সক্রিয় অবস্থায় পুনঃপ্রবেশ না করা পর্যন্ত ব্যাকগ্রাউন্ডের কাজ অনুমোদিত নয়।

যে অ্যাপগুলি সাধারণত ফ্রেমওয়ার্ক-সমর্থিত লাইফসাইকেল API ব্যবহার করে – যেমন পরিষেবা , JobScheduler , এবং Jetpack WorkManager – এই পরিবর্তনগুলি দ্বারা প্রভাবিত হওয়া উচিত নয়৷

ব্যবহারকারীর অভিজ্ঞতা

ব্যবহারকারীরা কীভাবে খারিজযোগ্য নয় এমন বিজ্ঞপ্তিগুলি উপভোগ করেন তার পরিবর্তনগুলি

যদি আপনার অ্যাপ ব্যবহারকারীদের কাছে অ-খারিজ ফোরগ্রাউন্ড বিজ্ঞপ্তি দেখায়, তাহলে Android 14 ব্যবহারকারীদের এই ধরনের বিজ্ঞপ্তি খারিজ করার অনুমতি দেওয়ার জন্য আচরণ পরিবর্তন করেছে।

এই পরিবর্তনটি এমন অ্যাপের ক্ষেত্রে প্রযোজ্য যা ব্যবহারকারীদের Notification.FLAG_ONGOING_EVENT এর মাধ্যমে Notification.Builder#setOngoing(true) বা NotificationCompat.Builder#setOngoing(true) সেট করে ফোরগ্রাউন্ড বিজ্ঞপ্তি খারিজ করা থেকে বাধা দেয়। FLAG_ONGOING_EVENT এর আচরণ পরিবর্তিত হয়েছে যাতে ব্যবহারকারীর দ্বারা এই ধরনের বিজ্ঞপ্তিগুলিকে খারিজ করা যায়৷

নিম্নলিখিত শর্তে এই ধরনের বিজ্ঞপ্তিগুলি এখনও খারিজযোগ্য নয়:

• ফোন লক হয়ে গেলে
• যদি ব্যবহারকারী একটি ক্লিয়ার অল নোটিফিকেশন অ্যাকশন নির্বাচন করে (যা দুর্ঘটনাজনিত বরখাস্তের ক্ষেত্রে সাহায্য করে)

এছাড়াও, এই নতুন আচরণ নিম্নলিখিত ব্যবহারের ক্ষেত্রে বিজ্ঞপ্তিগুলিতে প্রযোজ্য নয়:

• CallStyle বিজ্ঞপ্তি
• এন্টারপ্রাইজের জন্য ডিভাইস পলিসি কন্ট্রোলার (ডিপিসি) এবং সমর্থনকারী প্যাকেজ
• মিডিয়া বিজ্ঞপ্তি
• ডিফল্ট অনুসন্ধান নির্বাচক প্যাকেজ

ডেটা সুরক্ষা তথ্য আরও দৃশ্যমান

ব্যবহারকারীর গোপনীয়তা বাড়ানোর জন্য, Android 14 সেই জায়গাগুলির সংখ্যা বাড়ায় যেখানে সিস্টেমটি Play Console ফর্মে আপনার ঘোষিত তথ্য দেখায়। বর্তমানে, ব্যবহারকারীরা Google Play-তে আপনার অ্যাপের তালিকায় ডেটা নিরাপত্তা বিভাগে এই তথ্য দেখতে পারেন।

আমরা আপনাকে আপনার অ্যাপ্লিকেশানের অবস্থান ডেটা ভাগ করে নেওয়ার নীতিগুলি পর্যালোচনা করতে এবং আপনার অ্যাপের Google Play ডেটা সুরক্ষা বিভাগে যেকোন প্রযোজ্য আপডেট করার জন্য কিছুক্ষণ সময় নিতে উত্সাহিত করি৷

Android 14-এ ডেটা সুরক্ষা তথ্য কীভাবে আরও দৃশ্যমান হয় সে সম্পর্কে গাইডে আরও জানুন।

অ্যাক্সেসযোগ্যতা

নন-লিনিয়ার ফন্ট স্কেলিং ২০০% এ

Starting in Android 14, the system supports font scaling up to 200%, providing low-vision users with additional accessibility options that align with Web Content Accessibility Guidelines (WCAG).

If you already use scaled pixels (sp) units to define text sizing, then this change probably won't have a high impact on your app. However, you should perform UI testing with the maximum font size enabled (200%) to ensure that your app can accommodate larger font sizes without impacting usability.

নিরাপত্তা

ন্যূনতম ইনস্টলযোগ্য টার্গেট API স্তর

Android 14 দিয়ে শুরু করে, 23-এর কম targetSdkVersion সহ অ্যাপ ইনস্টল করা যাবে না। এই ন্যূনতম লক্ষ্য API স্তরের প্রয়োজনীয়তাগুলি পূরণ করার জন্য অ্যাপগুলির প্রয়োজন ব্যবহারকারীদের জন্য নিরাপত্তা এবং গোপনীয়তা উন্নত করে৷

নতুন অ্যান্ড্রয়েড সংস্করণে প্রবর্তিত নিরাপত্তা এবং গোপনীয়তা সুরক্ষাগুলিকে বাইপাস করার জন্য ম্যালওয়্যার প্রায়শই পুরানো API স্তরগুলিকে লক্ষ্য করে৷ উদাহরণস্বরূপ, Android 6.0 Marshmallow (API স্তর 23) দ্বারা 2015 সালে চালু করা রানটাইম অনুমতি মডেলের শিকার হওয়া এড়াতে কিছু ম্যালওয়্যার অ্যাপ 22-এর একটি targetSdkVersion ব্যবহার করে। এই Android 14 পরিবর্তন নিরাপত্তা এবং গোপনীয়তার উন্নতি এড়াতে ম্যালওয়্যারের জন্য কঠিন করে তোলে। একটি নিম্ন API স্তর লক্ষ্য করে একটি অ্যাপ ইনস্টল করার চেষ্টা করার ফলে একটি ইনস্টলেশন ব্যর্থ হবে, নিম্নলিখিত বার্তাটি লগক্যাটে উপস্থিত হবে:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7

Android 14-এ আপগ্রেড করা ডিভাইসগুলিতে, 23-এর কম targetSdkVersion সহ যেকোনও অ্যাপ ইনস্টল থাকবে।

আপনি যদি একটি পুরানো API স্তর লক্ষ্য করে একটি অ্যাপ্লিকেশন পরীক্ষা করতে চান, নিম্নলিখিত ADB কমান্ড ব্যবহার করুন:

adb install --bypass-low-target-sdk-block FILENAME.apk

মিডিয়া মালিকের প্যাকেজের নামগুলি হয়তো মুছে ফেলা হতে পারে

The media store supports queries for the OWNER_PACKAGE_NAME column, which indicates the app that stored a particular media file. Starting in Android 14, this value is redacted unless at least one of the following conditions is true:

• The app that stored the media file has a package name that is always visible to other apps.

• The app that queries the media store requests the QUERY_ALL_PACKAGES permission.

Learn more about how Android filters package visibility for privacy purposes.