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

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

অ্যান্ড্রয়েড ১৭-কে লক্ষ্য করে তৈরি অ্যাপগুলোর জন্য প্রযোজ্য আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।

নিরাপত্তা

অ্যান্ড্রয়েড ১৭-এ ডিভাইস ও অ্যাপ সুরক্ষার ক্ষেত্রে নিম্নলিখিত উন্নতিগুলো অন্তর্ভুক্ত করা হয়েছে।

ক্লিয়ারট্র্যাফিক অবচয় পরিকল্পনা ব্যবহার করে

ভবিষ্যতের রিলিজে, আমরা usesCleartextTraffic উপাদানটি অবচয় করার পরিকল্পনা করছি। যেসব অ্যাপকে আনএনক্রিপ্টেড (HTTP) সংযোগ তৈরি করতে হবে তাদের একটি নেটওয়ার্ক সুরক্ষা কনফিগারেশন ফাইল ব্যবহার করে স্থানান্তরিত করা উচিত, যা আপনাকে নির্দিষ্ট করতে দেয় যে আপনার অ্যাপটি কোন ডোমেনগুলিতে ক্লিয়ারটেক্সট সংযোগ তৈরি করতে হবে।

মনে রাখবেন যে নেটওয়ার্ক সুরক্ষা কনফিগারেশন ফাইলগুলি কেবলমাত্র API লেভেল 24 এবং তার উপরে সমর্থিত। যদি আপনার অ্যাপের ন্যূনতম API লেভেল 24 এর চেয়ে কম হয়, তাহলে আপনার নিম্নলিখিত দুটি কাজ করা উচিত:

• usesCleartextTraffic অ্যাট্রিবিউটটিকে true তে সেট করুন
• একটি নেটওয়ার্ক কনফিগারেশন ফাইল ব্যবহার করুন

যদি আপনার অ্যাপের সর্বনিম্ন API লেভেল 24 বা তার বেশি হয়, তাহলে আপনি একটি নেটওয়ার্ক কনফিগারেশন ফাইল ব্যবহার করতে পারেন এবং আপনাকে usesCleartextTraffic সেট করার প্রয়োজন নেই।

অন্তর্নিহিত URI অনুদান সীমাবদ্ধ করুন

বর্তমানে, যদি কোনও অ্যাপ এমন একটি URI দিয়ে একটি ইন্টেন্ট চালু করে যার মধ্যে Send , SendMultiple , অথবা ImageCapture অ্যাকশন থাকে, তাহলে সিস্টেম স্বয়ংক্রিয়ভাবে লক্ষ্য অ্যাপটিকে URI পড়ার এবং লেখার অনুমতি দেয়। আমরা Android 18-এ এই আচরণটি পরিবর্তন করার পরিকল্পনা করছি। এই কারণে, আমরা সুপারিশ করি যে অ্যাপগুলি সিস্টেমের উপর নির্ভর না করে স্পষ্টভাবে প্রাসঙ্গিক URI অনুমতি প্রদান করে।

প্রতি-অ্যাপ কীস্টোর সীমা

অ্যাপগুলোর অ্যান্ড্রয়েড কীস্টোরে অতিরিক্ত সংখ্যক কী তৈরি করা থেকে বিরত থাকা উচিত, কারণ এটি ডিভাইসের সমস্ত অ্যাপের জন্য একটি শেয়ার করা রিসোর্স। অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, সিস্টেম একটি অ্যাপের মালিকানাধীন কী-এর সংখ্যার উপর একটি সীমা আরোপ করেছে। অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণকে টার্গেট করা নন-সিস্টেম অ্যাপগুলোর জন্য এই সীমা হলো ৫০,০০০ কী এবং অন্য সব অ্যাপের জন্য ২০০,০০০ কী। সিস্টেম অ্যাপগুলোর জন্য এই সীমা ২০০,০০০ কী, তারা কোন এপিআই লেভেলকে টার্গেট করছে তা নির্বিশেষে।

যদি কোনো অ্যাপ নির্ধারিত সীমার বাইরে কী তৈরি করার চেষ্টা করে, তাহলে KeyStoreException ত্রুটির কারণে কী তৈরি করা ব্যর্থ হয়। এক্সেপশনটির মেসেজ স্ট্রিং-এ কী-এর সীমা সম্পর্কিত তথ্য থাকে। যদি অ্যাপটি এক্সেপশনটির উপর getNumericErrorCode() কল করে, তাহলে রিটার্ন ভ্যালুটি নির্ভর করে অ্যাপটি কোন API লেভেলকে টার্গেট করছে তার উপর:

• অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) বা তার উচ্চতর সংস্করণের অ্যাপগুলোর ক্ষেত্রে: getNumericErrorCode() নতুন ERROR_TOO_MANY_KEYS ভ্যালুটি রিটার্ন করে।
• অন্যান্য সকল অ্যাপের ক্ষেত্রে, getNumericErrorCode() ERROR_INCORRECT_USAGE রিটার্ন করে।

ব্যবহারকারীর অভিজ্ঞতা এবং সিস্টেম UI

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

ঘূর্ণনের পরে ডিফল্ট IME দৃশ্যমানতা পুনরুদ্ধার করা হচ্ছে

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, যখন ডিভাইসের কনফিগারেশন পরিবর্তন হয় (উদাহরণস্বরূপ, ঘূর্ণনের মাধ্যমে), এবং এটি অ্যাপ নিজেই পরিচালনা করে না, তখন পূর্ববর্তী IME দৃশ্যমানতা পুনরুদ্ধার করা হয় না।

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

• android:windowSoftInputMode অ্যাট্রিবিউটটিকে stateAlwaysVisible এ সেট করুন।
• আপনার অ্যাক্টিভিটির onCreate() পদ্ধতিতে প্রোগ্রাম্যাটিকভাবে সফট কীবোর্ডটি অনুরোধ করুন, অথবা onConfigurationChanged() পদ্ধতিটি যোগ করুন।

মানুষের ইনপুট

অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে, যা কিবোর্ড এবং টাচপ্যাডের মতো ব্যবহারকারীর ইনপুট ডিভাইসগুলোর সাথে অ্যাপের মিথস্ক্রিয়ার পদ্ধতিকে প্রভাবিত করে।

পয়েন্টার ক্যাপচারের সময় টাচপ্যাড ডিফল্টরূপে রিলেটিভ ইভেন্ট সরবরাহ করে।

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, যদি কোনও অ্যাপ View.requestPointerCapture() ব্যবহার করে পয়েন্টার ক্যাপচারের অনুরোধ করে এবং ব্যবহারকারী একটি টাচপ্যাড ব্যবহার করে, তাহলে সিস্টেমটি ব্যবহারকারীর স্পর্শ থেকে পয়েন্টার মুভমেন্ট এবং স্ক্রলিং জেসচার সনাক্ত করে এবং ক্যাপচার করা মাউস থেকে পয়েন্টার এবং স্ক্রোল হুইল মুভমেন্টের মতোই অ্যাপে রিপোর্ট করে। বেশিরভাগ ক্ষেত্রে, এটি ক্যাপচার করা মাউস সমর্থনকারী অ্যাপগুলিকে টাচপ্যাডের জন্য বিশেষ হ্যান্ডলিং লজিক যোগ করার প্রয়োজনীয়তা দূর করে। আরও বিস্তারিত জানার জন্য, View.POINTER_CAPTURE_MODE_RELATIVE এর ডকুমেন্টেশন দেখুন।

পূর্বে, সিস্টেমটি টাচপ্যাড থেকে অঙ্গভঙ্গি সনাক্ত করার চেষ্টা করত না, বরং টাচস্ক্রিন টাচের অনুরূপ ফর্ম্যাটে অ্যাপে কাঁচা, পরম আঙুলের অবস্থান সরবরাহ করত। যদি কোনও অ্যাপের এখনও এই পরম ডেটার প্রয়োজন হয়, তবে এটির পরিবর্তে View.POINTER_CAPTURE_MODE_ABSOLUTE সহ নতুন View.requestPointerCapture(int) পদ্ধতিটি কল করা উচিত।

মিডিয়া

অ্যান্ড্রয়েড ১৭-এ মিডিয়ার আচরণে নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

পটভূমির অডিও শক্তিশালীকরণ

অ্যান্ড্রয়েড ১৭ থেকে শুরু করে, অডিও ফ্রেমওয়ার্কটি অডিও প্লেব্যাক, অডিও ফোকাস অনুরোধ এবং ভলিউম পরিবর্তন API সহ ব্যাকগ্রাউন্ড অডিও ইন্টারঅ্যাকশনের উপর বিধিনিষেধ আরোপ করে যাতে ব্যবহারকারী ইচ্ছাকৃতভাবে এই পরিবর্তনগুলি শুরু করে।

যদি অ্যাপটি বৈধ জীবনচক্রের মধ্যে না থাকাকালীন অডিও API গুলি কল করার চেষ্টা করে, তাহলে অডিও প্লেব্যাক এবং ভলিউম পরিবর্তন API গুলি কোনও ব্যতিক্রম ছাড়াই বা ব্যর্থতার বার্তা প্রদান না করে নীরবে ব্যর্থ হয়। অডিও ফোকাস API ফলাফল কোড AUDIOFOCUS_REQUEST_FAILED সহ ব্যর্থ হয়।

প্রশমন কৌশল সহ আরও তথ্যের জন্য, পটভূমি অডিও শক্তকরণ দেখুন।

সংযোগ

ডিভাইসের সংযোগ ক্ষমতা উন্নত করার জন্য অ্যান্ড্রয়েড ১৭-এ নিম্নলিখিত পরিবর্তনগুলো অন্তর্ভুক্ত করা হয়েছে।

ব্লুটুথ সংযোগ বিচ্ছিন্ন হলে স্বয়ংক্রিয়ভাবে পুনরায় জোড়া লাগানোর ব্যবস্থা

অ্যান্ড্রয়েড ১৭-এ স্বয়ংক্রিয় পুনঃপেয়ারিং (autonomous re-pairing) চালু করা হয়েছে, যা একটি সিস্টেম-স্তরের উন্নয়ন এবং ব্লুটুথ সংযোগ বিচ্ছিন্ন হয়ে গেলে তা স্বয়ংক্রিয়ভাবে সমাধান করার জন্য ডিজাইন করা হয়েছে।

পূর্বে, কোনো বন্ড বিচ্ছিন্ন হয়ে গেলে, ব্যবহারকারীদের ম্যানুয়ালি সেটিংসে গিয়ে পেরিফেরালটি আনপেয়ার এবং তারপর পুনরায় পেয়ার করতে হতো। এই ফিচারটি অ্যান্ড্রয়েড ১৬-এর নিরাপত্তা উন্নতির উপর ভিত্তি করে তৈরি, যা ব্যবহারকারীদের ম্যানুয়ালি সেটিংসে গিয়ে পেরিফেরাল আনপেয়ার ও পুনরায় পেয়ার করার প্রয়োজন ছাড়াই সিস্টেমকে ব্যাকগ্রাউন্ডে বন্ড পুনঃস্থাপন করার সুযোগ দেয়।

যদিও বেশিরভাগ অ্যাপের জন্য কোডে কোনো পরিবর্তনের প্রয়োজন হবে না, ডেভেলপারদের ব্লুটুথ স্ট্যাকের নিম্নলিখিত আচরণগত পরিবর্তনগুলো সম্পর্কে সচেতন থাকা উচিত:

• নতুন পেয়ারিং কনটেক্সট: ACTION_PAIRING_REQUEST এ এখন EXTRA_PAIRING_CONTEXT নামক একটি এক্সট্রা অন্তর্ভুক্ত করা হয়েছে, যা অ্যাপগুলোকে একটি সাধারণ পেয়ারিং রিকোয়েস্ট এবং সিস্টেম দ্বারা স্বয়ংক্রিয়ভাবে শুরু হওয়া পুনরায় পেয়ারিং চেষ্টার মধ্যে পার্থক্য করতে সাহায্য করে।
• শর্তসাপেক্ষ কী আপডেট: বিদ্যমান নিরাপত্তা কীগুলো কেবল তখনই প্রতিস্থাপন করা হবে, যখন পুনঃজোড়া স্থাপন সফল হবে এবং নতুন সংযোগটি পূর্ববর্তী বন্ডের নিরাপত্তা স্তরের সমান বা তার চেয়ে বেশি হবে।
• ইনটেন্ট টাইমিং-এ পরিবর্তন: ACTION_KEY_MISSING ইনটেন্টটি এখন শুধুমাত্র তখনই ব্রডকাস্ট করা হবে যখন স্বয়ংক্রিয়ভাবে পুনরায় পেয়ারিং করার প্রচেষ্টা ব্যর্থ হয়। এর ফলে, যদি সিস্টেম ব্যাকগ্রাউন্ডে সফলভাবে বন্ডটি পুনরুদ্ধার করে, তবে অ্যাপে অপ্রয়োজনীয় এরর হ্যান্ডলিং কমে যায়।
• ব্যবহারকারীকে বিজ্ঞপ্তি: সিস্টেমটি নতুন UI বিজ্ঞপ্তি এবং ডায়ালগের মাধ্যমে পুনরায় পেয়ারিং পরিচালনা করে। ব্যবহারকারীরা যাতে পুনরায় সংযোগের বিষয়ে অবগত হন, তা নিশ্চিত করার জন্য তাদেরকে পুনরায় পেয়ারিং প্রচেষ্টাটি নিশ্চিত করতে অনুরোধ করা হবে।

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

• পেরিফেরাল ডিভাইস থেকে বন্ডের তথ্য ম্যানুয়ালি মুছে ফেলুন
• সেটিংস > সংযুক্ত ডিভাইস-এ গিয়ে ডিভাইসটি ম্যানুয়ালি আনপেয়ার করুন।