অ্যান্ড্রয়েড ১৭ প্ল্যাটফর্মে এমন কিছু আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। targetSdkVersion নির্বিশেষে, অ্যান্ড্রয়েড ১৭-এ চালিত সমস্ত অ্যাপের ক্ষেত্রে নিম্নলিখিত আচরণগত পরিবর্তনগুলি প্রযোজ্য। আপনার অ্যাপটি পরীক্ষা করে দেখা উচিত এবং তারপরে, যেখানে প্রযোজ্য, এই পরিবর্তনগুলিকে সমর্থন করার জন্য প্রয়োজন অনুযায়ী এটি সংশোধন করা উচিত।
অ্যান্ড্রয়েড ১৭-কে লক্ষ্য করে তৈরি অ্যাপগুলোর জন্য প্রযোজ্য আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।
মূল কার্যকারিতা
অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭)-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত রয়েছে, যা অ্যান্ড্রয়েড সিস্টেমের বিভিন্ন মূল সক্ষমতাকে সংশোধন বা প্রসারিত করে।
অ্যাপের মেমরি সীমা
আপনার অ্যাপ্লিকেশন এবং অ্যান্ড্রয়েড ব্যবহারকারীদের জন্য আরও স্থিতিশীল ও সুনির্দিষ্ট পরিবেশ তৈরি করতে, অ্যান্ড্রয়েড ১৭ ডিভাইসের মোট র্যামের উপর ভিত্তি করে অ্যাপ মেমরির সীমা নির্ধারণ করে। অ্যান্ড্রয়েড ১৭-এ, সিস্টেমের বেসলাইন স্থাপন করার জন্য এই সীমাগুলো সতর্কতার সাথে নির্ধারণ করা হয়। এর লক্ষ্য হলো, চরম মেমরি লিক এবং অন্যান্য অস্বাভাবিক পরিস্থিতিগুলো সিস্টেম-ব্যাপী অস্থিতিশীলতা সৃষ্টি করার আগেই সেগুলোকে নিয়ন্ত্রণ করা, যার ফলে UI আটকে যাওয়া, ব্যাটারির চার্জ দ্রুত শেষ হওয়া এবং অ্যাপ বন্ধ হয়ে যাওয়ার মতো সমস্যাগুলো এড়ানো যায়। যদিও আমরা আশা করছি যে বেশিরভাগ অ্যাপ সেশনের উপর এর প্রভাব ন্যূনতম হবে, তবুও আমরা মেমরির জন্য একটি বেসলাইন স্থাপন করা সহ নিম্নলিখিত সেরা অনুশীলনগুলো অনুসরণ করার পরামর্শ দিচ্ছি।
ApplicationExitInfo তে getDescription কল করে আপনি জানতে পারবেন আপনার অ্যাপ সেশনটি প্রভাবিত হয়েছে কিনা; যদি আপনার অ্যাপটি প্রভাবিত হয়ে থাকে, তাহলে এক্সিট রিজন হবে REASON_OTHER এবং ডেসক্রিপশনে অন্যান্য তথ্যের সাথে "MemoryLimiter:AnonSwap" স্ট্রিংটি থাকবে। এছাড়াও, মেমোরি লিমিট অতিক্রম করলে সংগৃহীত হিপ ডাম্প পেতে আপনি TRIGGER_TYPE_ANOMALY সহ ট্রিগার-ভিত্তিক প্রোফাইলিং ব্যবহার করতে পারেন।

মেমরি লিক খুঁজে পেতে আপনাকে সাহায্য করার জন্য, অ্যান্ড্রয়েড স্টুডিও পান্ডা সরাসরি অ্যান্ড্রয়েড স্টুডিও প্রোফাইলারের মধ্যে একটি ডেডিকেটেড টাস্ক হিসেবে লিকক্যানারি ইন্টিগ্রেশন যুক্ত করে, যা IDE-এর মধ্যেই প্রাসঙ্গিক থাকে এবং আপনার সোর্স কোডের সাথে সম্পূর্ণরূপে সমন্বিত হয়।
নিরাপত্তা
অ্যান্ড্রয়েড ১৭-এ ডিভাইস ও অ্যাপ সুরক্ষার ক্ষেত্রে নিম্নলিখিত উন্নতিগুলো অন্তর্ভুক্ত করা হয়েছে।
ক্লিয়ারট্র্যাফিক অবচয় পরিকল্পনা ব্যবহার করে
ভবিষ্যতের কোনো রিলিজে, আমরা usesCleartextTraffic এলিমেন্টটি বাতিল করার পরিকল্পনা করছি। যেসব অ্যাপের এনক্রিপ্টবিহীন (HTTP) সংযোগ স্থাপন করার প্রয়োজন, তাদের একটি নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ফাইল ব্যবহার শুরু করা উচিত, যা আপনাকে নির্দিষ্ট করে দেবে যে আপনার অ্যাপকে কোন কোন ডোমেইনের সাথে ক্লিয়ারটেক্সট সংযোগ স্থাপন করতে হবে।
মনে রাখবেন যে, নেটওয়ার্ক নিরাপত্তা কনফিগারেশন ফাইলগুলো শুধুমাত্র এপিআই লেভেল ২৪ এবং তার উপরের লেভেলগুলোতে সমর্থিত। যদি আপনার অ্যাপের সর্বনিম্ন এপিআই লেভেল ২৪-এর কম হয়, তবে আপনাকে নিম্নলিখিত দুটি কাজই করতে হবে:
-
usesCleartextTrafficঅ্যাট্রিবিউটটিtrueতে সেট করুন। - একটি নেটওয়ার্ক কনফিগারেশন ফাইল ব্যবহার করুন
যদি আপনার অ্যাপের সর্বনিম্ন API লেভেল 24 বা তার বেশি হয়, তাহলে আপনি একটি নেটওয়ার্ক কনফিগারেশন ফাইল ব্যবহার করতে পারেন এবং আপনার usesCleartextTraffic সেট করার প্রয়োজন নেই।
অন্তর্নিহিত URI অনুদান সীমাবদ্ধ করুন
Currently, if an app launches an intent with a URI that has the action Send,
SendMultiple, or ImageCapture, the system automatically grants the read and
write URI permissions to the target app. We plan to change this behavior in
Android 18. For this reason, we recommend that apps explicitly
grant the relevant URI permissions instead of relying on the system to grant
them.
প্রতি-অ্যাপ কীস্টোর সীমা
অ্যাপগুলোর অ্যান্ড্রয়েড কীস্টোরে অতিরিক্ত সংখ্যক কী তৈরি করা থেকে বিরত থাকা উচিত, কারণ এটি ডিভাইসের সমস্ত অ্যাপের জন্য একটি শেয়ার করা রিসোর্স। অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, সিস্টেম একটি অ্যাপের মালিকানাধীন কী-এর সংখ্যার উপর একটি সীমা আরোপ করেছে। অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করা নন-সিস্টেম অ্যাপগুলোর জন্য এই সীমা হলো ৫০,০০০ কী এবং অন্য সব অ্যাপের জন্য ২০০,০০০ কী। সিস্টেম অ্যাপগুলোর জন্য এই সীমা ২০০,০০০ কী, তারা কোন এপিআই লেভেলকে টার্গেট করছে তা নির্বিশেষে।
যদি কোনো অ্যাপ নির্ধারিত সীমার বাইরে কী তৈরি করার চেষ্টা করে, তাহলে KeyStoreException ত্রুটির কারণে কী তৈরি করা ব্যর্থ হয়। এক্সেপশনটির মেসেজ স্ট্রিং-এ কী-এর সীমা সম্পর্কিত তথ্য থাকে। যদি অ্যাপটি এক্সেপশনটির উপর getNumericErrorCode() কল করে, তাহলে রিটার্ন ভ্যালুটি নির্ভর করে অ্যাপটি কোন API লেভেলকে টার্গেট করছে তার উপর:
- অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণের অ্যাপগুলোর ক্ষেত্রে:
getNumericErrorCode()নতুনERROR_TOO_MANY_KEYSভ্যালুটি রিটার্ন করে। - অন্যান্য সকল অ্যাপের ক্ষেত্রে,
getNumericErrorCode()ERROR_INCORRECT_USAGEরিটার্ন করে।
ব্যবহারকারীর অভিজ্ঞতা এবং সিস্টেম UI
অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে, যার উদ্দেশ্য হলো আরও সামঞ্জস্যপূর্ণ ও স্বজ্ঞামূলক ব্যবহারকারীর অভিজ্ঞতা তৈরি করা।
ঘূর্ণনের পরে ডিফল্ট IME দৃশ্যমানতা পুনরুদ্ধার করা হচ্ছে
Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.
If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:
- Set the
android:windowSoftInputModeattribute tostateAlwaysVisible. - Programmatically request the soft keyboard in your activity's
onCreate()method, or add theonConfigurationChanged()method.
মানুষের ইনপুট
অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে, যা কিবোর্ড এবং টাচপ্যাডের মতো ব্যবহারকারীর ইনপুট ডিভাইসগুলোর সাথে অ্যাপের মিথস্ক্রিয়ার পদ্ধতিকে প্রভাবিত করে।
পয়েন্টার ক্যাপচারের সময় টাচপ্যাড ডিফল্টরূপে রিলেটিভ ইভেন্ট সরবরাহ করে।
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.
মিডিয়া
অ্যান্ড্রয়েড ১৭-এ মিডিয়ার আচরণে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
পটভূমির অডিও শক্তিশালীকরণ
অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অডিও ফ্রেমওয়ার্ক ব্যাকগ্রাউন্ডে অডিও ইন্টারঅ্যাকশনের উপর বিধিনিষেধ আরোপ করে। এর মধ্যে রয়েছে অডিও প্লেব্যাক, অডিও ফোকাস রিকোয়েস্ট এবং ভলিউম পরিবর্তনের এপিআই। এর উদ্দেশ্য হলো, এই পরিবর্তনগুলো যেন ব্যবহারকারীর ইচ্ছাকৃত উদ্যোগেই শুরু হয় তা নিশ্চিত করা।
অ্যাপটি যদি কোনো বৈধ লাইফসাইকেলে না থাকা অবস্থায় অডিও এপিআই কল করার চেষ্টা করে, তাহলে অডিও প্লেব্যাক এবং ভলিউম পরিবর্তনের এপিআইগুলো কোনো এক্সেপশন থ্রো না করে বা ব্যর্থতার বার্তা না দিয়ে নীরবে ব্যর্থ হয়। অডিও ফোকাস এপিআইটি AUDIOFOCUS_REQUEST_FAILED রেজাল্ট কোড সহ ব্যর্থ হয়।
প্রশমন কৌশল সহ আরও তথ্যের জন্য, ব্যাকগ্রাউন্ড অডিও হার্ডেনিং দেখুন।
সংযোগ
ডিভাইসের সংযোগ ক্ষমতা উন্নত করার জন্য অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।
ব্লুটুথ সংযোগ বিচ্ছিন্ন হলে স্বয়ংক্রিয়ভাবে পুনরায় জোড়া লাগানোর ব্যবস্থা
অ্যান্ড্রয়েড ১৭-এ স্বয়ংক্রিয় পুনঃ-পেয়ারিং (autonomous re-pairing) চালু করা হয়েছে, যা একটি সিস্টেম-স্তরের উন্নয়ন এবং ব্লুটুথ সংযোগ বিচ্ছিন্ন হয়ে গেলে তা স্বয়ংক্রিয়ভাবে সমাধান করার জন্য ডিজাইন করা হয়েছে।
পূর্বে, কোনো বন্ড বিচ্ছিন্ন হয়ে গেলে, ব্যবহারকারীদের ম্যানুয়ালি সেটিংসে গিয়ে পেরিফেরালটি আনপেয়ার এবং তারপর পুনরায় পেয়ার করতে হতো। এই ফিচারটি অ্যান্ড্রয়েড ১৬-এর নিরাপত্তা উন্নতির উপর ভিত্তি করে তৈরি, যা ব্যবহারকারীদের ম্যানুয়ালি সেটিংসে গিয়ে পেরিফেরাল আনপেয়ার ও পুনরায় পেয়ার করার প্রয়োজন ছাড়াই সিস্টেমকে ব্যাকগ্রাউন্ডে বন্ড পুনঃস্থাপন করার সুযোগ দেয়।
যদিও বেশিরভাগ অ্যাপের জন্য কোডে কোনো পরিবর্তনের প্রয়োজন হবে না, ডেভেলপারদের ব্লুটুথ স্ট্যাকের নিম্নলিখিত আচরণগত পরিবর্তনগুলো সম্পর্কে সচেতন থাকা উচিত:
- নতুন পেয়ারিং কনটেক্সট:
ACTION_PAIRING_REQUESTএ এখনEXTRA_PAIRING_CONTEXTনামক একটি এক্সট্রা অন্তর্ভুক্ত করা হয়েছে, যা অ্যাপগুলোকে একটি সাধারণ পেয়ারিং রিকোয়েস্ট এবং সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে শুরু হওয়া পুনরায় পেয়ারিং চেষ্টার মধ্যে পার্থক্য করতে সাহায্য করে। - শর্তসাপেক্ষ কী আপডেট: বিদ্যমান নিরাপত্তা কীগুলো কেবল তখনই প্রতিস্থাপন করা হবে, যখন পুনঃজোড়া স্থাপন সফল হবে এবং নতুন সংযোগটি পূর্ববর্তী বন্ডের নিরাপত্তা স্তরের সমান বা তার চেয়ে বেশি হবে।
- ইনটেন্ট টাইমিং-এ পরিবর্তন:
ACTION_KEY_MISSINGইনটেন্টটি এখন শুধুমাত্র তখনই ব্রডকাস্ট করা হবে যখন স্বয়ংক্রিয়ভাবে পুনরায় পেয়ারিং করার প্রচেষ্টা ব্যর্থ হয়। এর ফলে, যদি সিস্টেম ব্যাকগ্রাউন্ডে সফলভাবে বন্ডটি পুনরুদ্ধার করে, তবে অ্যাপে অপ্রয়োজনীয় এরর হ্যান্ডলিং কমে যায়। - ব্যবহারকারীকে বিজ্ঞপ্তি: সিস্টেমটি নতুন UI বিজ্ঞপ্তি এবং ডায়ালগের মাধ্যমে পুনরায় পেয়ারিং পরিচালনা করে। ব্যবহারকারীরা যাতে পুনরায় সংযোগের বিষয়ে অবগত হন, তা নিশ্চিত করার জন্য তাদেরকে পুনরায় পেয়ারিং প্রচেষ্টাটি নিশ্চিত করতে অনুরোধ করা হবে।
পেরিফেরাল ডিভাইস নির্মাতা এবং সহযোগী অ্যাপ ডেভেলপারদের যাচাই করে দেখা উচিত যে হার্ডওয়্যার এবং অ্যাপ বন্ড ট্রানজিশনগুলো সুষ্ঠুভাবে সামাল দিতে পারে কিনা। এই আচরণটি পরীক্ষা করার জন্য, নিম্নলিখিত পদ্ধতিগুলোর যেকোনো একটি ব্যবহার করে একটি রিমোট বন্ড লস সিমুলেট করুন:
- পেরিফেরাল ডিভাইস থেকে বন্ডের তথ্য ম্যানুয়ালি মুছে ফেলুন
- সেটিংস > সংযুক্ত ডিভাইস-এ গিয়ে ডিভাইসটি ম্যানুয়ালি আনপেয়ার করুন।