অ্যান্ড্রয়েড ১৭ প্ল্যাটফর্মে এমন কিছু আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। targetSdkVersion নির্বিশেষে, অ্যান্ড্রয়েড ১৭-এ চালিত সমস্ত অ্যাপের ক্ষেত্রে নিম্নলিখিত আচরণগত পরিবর্তনগুলি প্রযোজ্য। আপনার অ্যাপটি পরীক্ষা করে দেখা উচিত এবং তারপরে, যেখানে প্রযোজ্য, এই পরিবর্তনগুলিকে সমর্থন করার জন্য প্রয়োজন অনুযায়ী এটি সংশোধন করা উচিত।
অ্যান্ড্রয়েড ১৭-কে লক্ষ্য করে তৈরি অ্যাপগুলোর জন্য প্রযোজ্য আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।
মূল কার্যকারিতা
অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭)-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত রয়েছে, যা অ্যান্ড্রয়েড সিস্টেমের বিভিন্ন মূল সক্ষমতাকে সংশোধন বা প্রসারিত করে।
অ্যাপের মেমরি সীমা
অ্যান্ড্রয়েড ১৭ আপনার অ্যাপ এবং অ্যান্ড্রয়েড ব্যবহারকারীদের জন্য আরও স্থিতিশীল ও সুনির্দিষ্ট পরিবেশ তৈরি করতে ডিভাইসের মোট র্যামের উপর ভিত্তি করে অ্যাপ মেমরির সীমা নির্ধারণ করে। অ্যান্ড্রয়েড ১৭-এ, সিস্টেমের বেসলাইন স্থাপন করার জন্য এই সীমাগুলো সতর্কতার সাথে নির্ধারণ করা হয়। এর লক্ষ্য হলো, চরম মেমরি লিক এবং অন্যান্য অস্বাভাবিক ঘটনাগুলো সিস্টেম-ব্যাপী অস্থিতিশীলতা সৃষ্টি করার আগেই সেগুলোকে নিয়ন্ত্রণ করা, যার ফলে UI আটকে যাওয়া, ব্যাটারির চার্জ দ্রুত শেষ হওয়া এবং অ্যাপ বন্ধ হয়ে যাওয়ার মতো সমস্যাগুলো এড়ানো যায়। যদিও আমরা আশা করছি যে বেশিরভাগ অ্যাপ সেশনের উপর এর প্রভাব ন্যূনতম হবে, তবুও আমরা মেমরির জন্য একটি বেসলাইন স্থাপন করা সহ নিম্নলিখিত সেরা অনুশীলনগুলো অনুসরণ করার পরামর্শ দিচ্ছি।
ApplicationExitInfo তে getDescription কল করে আপনি জানতে পারবেন আপনার অ্যাপ সেশনটি প্রভাবিত হয়েছে কিনা; যদি আপনার অ্যাপটি প্রভাবিত হয়ে থাকে, তাহলে এক্সিট রিজন হবে REASON_OTHER এবং ডেসক্রিপশনে অন্যান্য তথ্যের সাথে "MemoryLimiter:AnonSwap" স্ট্রিংটি থাকবে। এছাড়াও, মেমোরি লিমিট অতিক্রম করলে সংগৃহীত হিপ ডাম্প পেতে আপনি TRIGGER_TYPE_ANOMALY সহ ট্রিগার-ভিত্তিক প্রোফাইলিং ব্যবহার করতে পারেন।
আপনার অ্যাপের মেমরি পরিচালনা সংক্রান্ত ডকুমেন্টেশনটি আপনার অ্যাপের মেমরি সমস্যা নির্ণয় করতে এবং এর রিসোর্স ব্যবহার অপ্টিমাইজ করতে সাহায্য করার জন্য তথ্য প্রদান করে।
মেমরির সীমাবদ্ধতার অধীনে আপনার অ্যাপের আচরণ পরীক্ষা করুন
যেসব ডিভাইসে মেমরি লিমিট আরোপ করা হয়, সেগুলোর ক্ষেত্রে আপনি অ্যান্ড্রয়েড ডিবাগ ব্রিজ ( adb ) ব্যবহার করে তা সমন্বয় বা নিষ্ক্রিয় করতে পারেন। শেল কমান্ড am মেমরি লিমিট সমন্বয় করার জন্য তিনটি সাবকমান্ড প্রদান করে। (যেসব ডিভাইসে মেমরি লিমিট আরোপ করা হয় না, সেগুলোতে এই কমান্ডগুলোর কোনো প্রভাব নেই।)
-
am memory-limiter ignore <uid>|none|all -
am memory-limiter manual <pid> <limit>|max|none -
am memory-limiter status
-
ignore মেমরি লিমিটারকে কিছু বা সমস্ত প্রসেস উপেক্ষা করার নির্দেশ দেয়। একটি UID (অ্যান্ড্রয়েড ইউজার আইডি) পাস করলে, মেমরি লিমিটার সেই UID-এর সাথে যুক্ত সমস্ত প্রসেসের উপর বিধিনিষেধ আরোপ করা উপেক্ষা করে। আপনি
all(সমস্ত অ্যাপ উপেক্ষা করতে) বাnone(কোনো অ্যাপ উপেক্ষা না করতে) পাস করতে পারেন।noneপাস করলেam memory-limiter ignoreএর পূর্ববর্তী যেকোনো কল বাতিল হয়ে যায়।আপনি যদি মেমরি লিমিটারকে কোনো UID উপেক্ষা করার নির্দেশ দেন, তারপরেও
am memory-limiter manualকল করে অ্যাপের ভেতরের কোনো প্রসেসে ম্যানুয়ালি মেমরি লিমিট প্রয়োগ করতে পারবেন।-
manual সিস্টেমকে নির্দিষ্ট PID (প্রসেস আইডি) সহ প্রসেসটির উপর একটি মেমরি সীমাবদ্ধতা আরোপ করার নির্দেশ দেয়। মেমরি সীমাবদ্ধতাটি মেগাবাইটের (MB) একটি পূর্ণসংখ্যা হিসাবে নির্দিষ্ট করা হয়; উদাহরণস্বরূপ,
30পাস করলে প্রসেসটি 30 মেগাবাইট মেমরিতে সীমাবদ্ধ থাকবে।maxপাস করলে সেই প্রসেসের উপর থেকে সমস্ত মেমরি সীমাবদ্ধতা তুলে নেওয়া হয়।noneপাস করলে প্রসেসটিতে সেট করা যেকোনো ম্যানুয়াল সীমাবদ্ধতা তুলে নেওয়া হয় এবং সিস্টেমের ডিফল্ট সীমাবদ্ধতা (যদি থাকে) পুনরুদ্ধার করা হয়।-
status মেমরি লিমিটারের বর্তমান অবস্থা রিপোর্ট করে। এই অবস্থায় দৃশ্যমান এবং অদৃশ্য প্রসেসগুলোর উপর আরোপিত মেমরি সীমা অন্তর্ভুক্ত থাকে।
গোপনীয়তা
ব্যবহারকারীর গোপনীয়তা উন্নত করার জন্য অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
এসএমএস ওটিপি সুরক্ষা
Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).
In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.
Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.
During this three hour delay, the SMS_RECEIVED_ACTION broadcast is
withheld and SMS provider database queries are filtered. The
SMS message is available to these apps after the delay. This change applies to
all apps, regardless of their target API level.
Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.
নিরাপত্তা
অ্যান্ড্রয়েড ১৭-এ ডিভাইস ও অ্যাপ সুরক্ষার ক্ষেত্রে নিম্নলিখিত উন্নতিগুলো অন্তর্ভুক্ত করা হয়েছে।
ক্লিয়ারট্র্যাফিক অবচয় পরিকল্পনা ব্যবহার করে
In a future release, we plan to deprecate the usesCleartextTraffic element.
Apps that need to make unencrypted (HTTP) connections should migrate to
using a network security configuration file, which lets you
specify which domains your app needs to make cleartext connections to.
Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:
- Set the
usesCleartextTrafficattribute totrue - Use a network configuration file
If your app's minimum API level is 24 or higher, you can use a network
configuration file and you don't need to set usesCleartextTraffic.
অন্তর্নিহিত URI অনুদান সীমাবদ্ধ করুন
Currently, if an app launches an intent with a URI that has the action
ACTION_SEND, ACTION_SEND_MULTIPLE, or
ACTION_IMAGE_CAPTURE, the system automatically grants the read and
write URI permissions to the target app. Starting in Android 18, the system will
no longer automatically grant these permissions. For this reason, we recommend
that apps explicitly grant the
relevant URI permissions instead of relying on the system to grant them.
To detect the usage of these intents in your app, use StrictMode with
detectImplicitUriPermissionGrant() to trigger a violation:
Kotlin
val policy = StrictMode.VmPolicy.Builder() .detectImplicitUriPermissionGrant() .penaltyLog() .build() StrictMode.setVmPolicy(policy)
Java
StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder() .detectImplicitUriPermissionGrant() .penaltyLog() .build(); StrictMode.setVmPolicy(policy);
Alternatively, you can monitor for logged exceptions containing the message
Please set the grant explicitly in the app that appears when system implicitly
sets the grant. You can monitor for these logs
using the following adb command:
adb logcat | grep "Please set the grant explicitly in the app"
To explicitly grant the necessary permissions, add the
FLAG_GRANT_READ_URI_PERMISSION flag to ACTION_SEND and
ACTION_SEND_MULTIPLE intents:
Kotlin
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
Java
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
Include both FLAG_GRANT_READ_URI_PERMISSION and
FLAG_GRANT_WRITE_URI_PERMISSION flags for
ACTION_IMAGE_CAPTURE intents:
Kotlin
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)
Java
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);
প্রতি-অ্যাপ কীস্টোর সীমা
Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.
If an app attempts to create keys beyond the limit, the creation fails with a
KeyStoreException. The exception's message string contains information
about the key limit. If the app calls getNumericErrorCode() on the
exception, the return value depends on what API level the app targets:
- Apps targeting Android 17 (API level 37) or higher:
getNumericErrorCode()returns the newERROR_TOO_MANY_KEYSvalue. - All other apps:
getNumericErrorCode()returnsERROR_INCORRECT_USAGE.
ক্রস প্রোফাইল লুপব্যাক ট্র্যাফিক ব্লক করুন
অ্যান্ড্রয়েড ১৭ থেকে, ক্রস-প্রোফাইল লুপব্যাক ট্র্যাফিক ডিফল্টরূপে আর অনুমোদিত নয়। একই প্রোফাইলের মধ্যেকার লুপব্যাক ট্র্যাফিক এর দ্বারা প্রভাবিত হবে না। এই পরিবর্তনটি অ্যান্ড্রয়েড ১৭ বা তার উচ্চতর সংস্করণে চালিত সমস্ত অ্যাপের ক্ষেত্রে প্রযোজ্য, অ্যাপটি কোন এপিআই লেভেলকে টার্গেট করে তা নির্বিশেষে।
ব্যবহারকারীর অভিজ্ঞতা এবং সিস্টেম UI
অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে, যার উদ্দেশ্য হলো আরও সামঞ্জস্যপূর্ণ ও স্বজ্ঞামূলক ব্যবহারকারীর অভিজ্ঞতা তৈরি করা।
ঘূর্ণনের পরে ডিফল্ট IME দৃশ্যমানতা পুনরুদ্ধার করা হচ্ছে
অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, যখন ডিভাইসের কনফিগারেশন পরিবর্তিত হয় (উদাহরণস্বরূপ, ডিভাইস ঘোরানোর মাধ্যমে), এবং এই পরিবর্তনটি অ্যাপ নিজে থেকে নিয়ন্ত্রণ করে না, তখন পূর্ববর্তী IME দৃশ্যমানতা পুনরুদ্ধার করা হয় না।
যদি আপনার অ্যাপের কনফিগারেশনে এমন কোনো পরিবর্তন আসে যা অ্যাপটি নিজে থেকে সামলাতে পারে না, এবং পরিবর্তনের পরেও অ্যাপটির কিবোর্ড দৃশ্যমান থাকা প্রয়োজন হয়, তবে আপনাকে অবশ্যই এর জন্য সুস্পষ্টভাবে অনুরোধ করতে হবে। আপনি নিম্নলিখিত উপায়গুলোর যেকোনো একটির মাধ্যমে এই অনুরোধটি করতে পারেন:
-
android:windowSoftInputModeঅ্যাট্রিবিউটটিকেstateAlwaysVisibleএ সেট করুন। - আপনার অ্যাক্টিভিটির
onCreate()মেথডে প্রোগ্রাম্যাটিকভাবে সফট কিবোর্ডের জন্য অনুরোধ করুন, অথবাonConfigurationChanged()মেথডটি যোগ করুন।
মানুষের ইনপুট
অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে, যা কিবোর্ড এবং টাচপ্যাডের মতো ব্যবহারকারীর ইনপুট ডিভাইসগুলোর সাথে অ্যাপের মিথস্ক্রিয়ার পদ্ধতিকে প্রভাবিত করে।
পয়েন্টার ক্যাপচারের সময় টাচপ্যাড ডিফল্টরূপে রিলেটিভ ইভেন্ট সরবরাহ করে।
Beginning with Android 17, if an app requests pointer capture using
View.requestPointerCapture() and the user uses a touchpad, the system
recognizes pointer movement and scrolling gestures from the user's touches and
reports them to the app in the same way as pointer and scroll wheel movements
from a captured mouse. In most cases, this removes the need for apps that
support captured mice to add special handling logic for touchpads. For more
details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.
Previously, the system did not attempt to recognize gestures from the touchpad,
and instead delivered the raw, absolute finger locations to the app in a similar
format to touchscreen touches. If an app still requires this absolute data, it
should call the new View.requestPointerCapture(int) method with
View.POINTER_CAPTURE_MODE_ABSOLUTE instead.
মিডিয়া
অ্যান্ড্রয়েড ১৭-এ মিডিয়ার আচরণে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
পটভূমির অডিও শক্তিশালীকরণ
Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.
If the app tries to call audio APIs while the app is not in a valid lifecycle,
the audio playback and volume change APIs fail silently without throwing an
exception or providing a failure message. The audio focus API fails with the
result code AUDIOFOCUS_REQUEST_FAILED.
For more information, including mitigation strategies, see Background audio hardening.
সংযোগ
ডিভাইসের সংযোগ ক্ষমতা উন্নত করার জন্য অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
ব্লুটুথ সংযোগ বিচ্ছিন্ন হলে স্বয়ংক্রিয়ভাবে পুনরায় জোড়া লাগানোর ব্যবস্থা
অ্যান্ড্রয়েড ১৭-এ স্বয়ংক্রিয় পুনঃ-পেয়ারিং (autonomous re-pairing) চালু করা হয়েছে, যা একটি সিস্টেম-স্তরের উন্নয়ন এবং ব্লুটুথ সংযোগ বিচ্ছিন্ন হয়ে গেলে তা স্বয়ংক্রিয়ভাবে সমাধান করার জন্য ডিজাইন করা হয়েছে।
পূর্বে, কোনো বন্ড বিচ্ছিন্ন হয়ে গেলে, ব্যবহারকারীদের ম্যানুয়ালি সেটিংসে গিয়ে পেরিফেরালটি আনপেয়ার এবং তারপর পুনরায় পেয়ার করতে হতো। এই ফিচারটি অ্যান্ড্রয়েড ১৬-এর নিরাপত্তা উন্নতির উপর ভিত্তি করে তৈরি, যা ব্যবহারকারীদের ম্যানুয়ালি সেটিংসে গিয়ে পেরিফেরাল আনপেয়ার ও পুনরায় পেয়ার করার প্রয়োজন ছাড়াই সিস্টেমকে ব্যাকগ্রাউন্ডে বন্ড পুনঃস্থাপন করার সুযোগ দেয়।
যদিও বেশিরভাগ অ্যাপের জন্য কোডে কোনো পরিবর্তনের প্রয়োজন হবে না, ডেভেলপারদের ব্লুটুথ স্ট্যাকের নিম্নলিখিত আচরণগত পরিবর্তনগুলো সম্পর্কে সচেতন থাকা উচিত:
- নতুন পেয়ারিং কনটেক্সট:
ACTION_PAIRING_REQUESTএ এখনEXTRA_PAIRING_CONTEXTনামক একটি এক্সট্রা অন্তর্ভুক্ত করা হয়েছে, যা অ্যাপগুলোকে একটি সাধারণ পেয়ারিং রিকোয়েস্ট এবং সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে শুরু হওয়া পুনরায় পেয়ারিং চেষ্টার মধ্যে পার্থক্য করতে সাহায্য করে। - শর্তসাপেক্ষ কী আপডেট: বিদ্যমান নিরাপত্তা কীগুলো কেবল তখনই প্রতিস্থাপন করা হবে, যখন পুনঃজোড়া স্থাপন সফল হবে এবং নতুন সংযোগটি পূর্ববর্তী বন্ডের নিরাপত্তা স্তরের সমান বা তার চেয়ে বেশি হবে।
- ইনটেন্ট টাইমিং-এ পরিবর্তন:
ACTION_KEY_MISSINGইনটেন্টটি এখন শুধুমাত্র তখনই ব্রডকাস্ট করা হবে যখন স্বয়ংক্রিয়ভাবে পুনরায় পেয়ারিং করার প্রচেষ্টা ব্যর্থ হয়। এর ফলে, যদি সিস্টেম ব্যাকগ্রাউন্ডে সফলভাবে বন্ডটি পুনরুদ্ধার করে, তবে অ্যাপে অপ্রয়োজনীয় এরর হ্যান্ডলিং কমে যায়। - ব্যবহারকারীকে বিজ্ঞপ্তি: সিস্টেমটি নতুন UI বিজ্ঞপ্তি এবং ডায়ালগের মাধ্যমে পুনরায় পেয়ারিং পরিচালনা করে। ব্যবহারকারীরা যাতে পুনরায় সংযোগের বিষয়ে অবগত হন, তা নিশ্চিত করার জন্য তাদেরকে পুনরায় পেয়ারিং প্রচেষ্টাটি নিশ্চিত করতে অনুরোধ করা হবে।
পেরিফেরাল ডিভাইস নির্মাতা এবং সহযোগী অ্যাপ ডেভেলপারদের যাচাই করে দেখা উচিত যে হার্ডওয়্যার এবং অ্যাপ বন্ড ট্রানজিশনগুলো সুষ্ঠুভাবে সামাল দিতে পারে কিনা। এই আচরণটি পরীক্ষা করার জন্য, নিম্নলিখিত পদ্ধতিগুলোর যেকোনো একটি ব্যবহার করে একটি রিমোট বন্ড লস সিমুলেট করুন:
- পেরিফেরাল ডিভাইস থেকে বন্ডের তথ্য ম্যানুয়ালি মুছে ফেলুন
- সেটিংস > সংযুক্ত ডিভাইস-এ গিয়ে ডিভাইসটি ম্যানুয়ালি আনপেয়ার করুন।