আচরণ পরিবর্তন: API 29+ টার্গেট করা অ্যাপ

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

অ্যান্ড্রয়েড ১০-এ চালিত সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।

নন-এসডিকে ইন্টারফেস সীমাবদ্ধতার আপডেট

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

আপনি যদি অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) টার্গেট না করেন, তাহলে এই পরিবর্তনগুলোর কিছু হয়তো আপনাকে তাৎক্ষণিকভাবে প্রভাবিত করবে না। তবে, যদিও আপনি বর্তমানে কিছু নন-এসডিকে ইন্টারফেস ব্যবহার করতে পারেন ( যা আপনার অ্যাপের টার্গেট এপিআই লেভেলের উপর নির্ভর করে ), যেকোনো নন-এসডিকে মেথড বা ফিল্ড ব্যবহার করলে আপনার অ্যাপটি ভেঙে যাওয়ার ঝুঁকি সবসময়ই অনেক বেশি থাকে।

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

আরও জানতে, Android 10-এ নন-এসডিকে ইন্টারফেস সীমাবদ্ধতার আপডেট এবং নন-এসডিকে ইন্টারফেসের উপর সীমাবদ্ধতা দেখুন।

ভাগ করা স্মৃতি

Ashmem /proc/<pid>/maps-এ ডালভিক ম্যাপের ফরম্যাট পরিবর্তন করেছে, যা সরাসরি ম্যাপ ফাইল পার্স করে এমন অ্যাপগুলোকে প্রভাবিত করছে। অ্যাপ্লিকেশন ডেভেলপারদের উচিত Android 10 বা তার উচ্চতর সংস্করণে চালিত ডিভাইসগুলোতে /proc/<pid>/maps-এর ফরম্যাট পরীক্ষা করা এবং অ্যাপটি যদি ডালভিক ম্যাপ ফরম্যাটের উপর নির্ভরশীল হয়, তবে সেই অনুযায়ী পার্স করা।

অ্যান্ড্রয়েড ১০-কে লক্ষ্য করে তৈরি অ্যাপগুলো সরাসরি অ্যাশমেম (/dev/ashmem) ব্যবহার করতে পারে না এবং এর পরিবর্তে অবশ্যই এনডিকে-এর ASharedMemory ক্লাসের মাধ্যমে শেয়ার্ড মেমোরি অ্যাক্সেস করতে হবে। এছাড়াও, অ্যাপগুলো বিদ্যমান অ্যাশমেম ফাইল ডেসক্রিপ্টরগুলোতে সরাসরি IOCTL করতে পারে না এবং এর পরিবর্তে শেয়ার্ড মেমোরি রিজিয়ন তৈরির জন্য অবশ্যই এনডিকে-এর ASharedMemory ক্লাস অথবা অ্যান্ড্রয়েড জাভা এপিআই ব্যবহার করতে হবে। এই পরিবর্তনটি শেয়ার্ড মেমোরির সাথে কাজ করার ক্ষেত্রে নিরাপত্তা ও দৃঢ়তা বৃদ্ধি করে, যা সামগ্রিকভাবে অ্যান্ড্রয়েডের পারফরম্যান্স এবং নিরাপত্তা উন্নত করে।

অ্যাপ হোম ডিরেক্টরির জন্য এক্সিকিউট পারমিশন সরানো হয়েছে

অ্যাপের রাইটেবল হোম ডিরেক্টরি থেকে ফাইল চালানো একটি W^X লঙ্ঘন । অ্যাপগুলোর শুধুমাত্র সেই বাইনারি কোড লোড করা উচিত যা অ্যাপটির APK ফাইলের মধ্যে এমবেড করা থাকে।

অ্যান্ড্রয়েড ১০-কে লক্ষ্য করে তৈরি অবিশ্বস্ত অ্যাপগুলো তাদের হোম ডিরেক্টরির ভেতরের ফাইলগুলোর ওপর সরাসরি execve() কল করতে পারে না।

এছাড়াও, অ্যান্ড্রয়েড ১০-কে লক্ষ্য করে তৈরি অ্যাপগুলো dlopen() দিয়ে খোলা ফাইল থেকে এক্সিকিউটেবল কোড ইন-মেমোরি পরিবর্তন করতে পারে না এবং সেই পরিবর্তনগুলো ডিস্কে লেখা হবে বলেও আশা করে না, কারণ লাইব্রেরিটিকে কোনো রাইটেবল ফাইল ডেসক্রিপ্টরের মাধ্যমে PROT_EXEC হিসেবে ম্যাপ করা যায় না। এর মধ্যে টেক্সট রিলোকেশনযুক্ত যেকোনো শেয়ার্ড অবজেক্ট ( .so ) ফাইলও অন্তর্ভুক্ত।

অ্যান্ড্রয়েড রানটাইম শুধুমাত্র সিস্টেম-জেনারেটেড OAT ফাইল গ্রহণ করে।

অ্যান্ড্রয়েড রানটাইম (ART) এখন আর অ্যাপ্লিকেশন প্রসেস থেকে dex2oat কল করে না। এই পরিবর্তনের ফলে ART শুধুমাত্র সিস্টেম দ্বারা তৈরি OAT ফাইলগুলোই গ্রহণ করবে।

ART-তে AOT-এর সঠিকতা বলবৎ করা

অতীতে, অ্যান্ড্রয়েড রানটাইম (ART) দ্বারা সম্পাদিত অ্যাহেড-অফ-টাইম (AOT) কম্পাইলেশন রানটাইম ক্র্যাশের কারণ হতে পারত, যদি কম্পাইল টাইম এবং রানটাইমে ক্লাসপাথ এনভায়রনমেন্ট একই না থাকত। অ্যান্ড্রয়েড ১০ এবং এর পরবর্তী সংস্করণগুলোতে এই এনভায়রনমেন্ট কনটেক্সটগুলো সর্বদা একই থাকা আবশ্যক, যার ফলে এর আচরণে নিম্নলিখিত পরিবর্তনগুলো এসেছে:

• কাস্টম ক্লাস লোডার—অর্থাৎ, অ্যাপ দ্বারা লিখিত ক্লাস লোডার, যা dalvik.system প্যাকেজের ক্লাস লোডার থেকে ভিন্ন—AOT-কম্পাইল করা হয় না। এর কারণ হলো, রানটাইমে ART কাস্টমাইজড ক্লাস লুকআপ ইমপ্লিমেন্টেশন সম্পর্কে জানতে পারে না।
• সেকেন্ডারি ডেক্স ফাইল—অর্থাৎ, যে ডেক্স ফাইলগুলো প্রাইমারি APK-তে নেই এবং অ্যাপগুলো ম্যানুয়ালি লোড করে—সেগুলো ব্যাকগ্রাউন্ডে AOT-কম্পাইল করা হয়। এর কারণ হলো, প্রথমবার ব্যবহারের কম্পাইলেশন বেশ ব্যয়বহুল হতে পারে, যা এক্সিকিউশনের আগে অনাকাঙ্ক্ষিত বিলম্ব ঘটাতে পারে। উল্লেখ্য যে, অ্যাপের ক্ষেত্রে স্প্লিট পদ্ধতি গ্রহণ করা এবং সেকেন্ডারি ডেক্স ফাইল থেকে সরে আসা বাঞ্ছনীয়।
• অ্যান্ড্রয়েডের শেয়ার্ড লাইব্রেরিগুলো (অ্যান্ড্রয়েড ম্যানিফেস্টের <library> এবং <uses-library> এন্ট্রিগুলো) প্ল্যাটফর্মটির পূর্ববর্তী সংস্করণগুলোতে ব্যবহৃত ক্লাস লোডার হায়ারার্কি থেকে ভিন্ন একটি হায়ারার্কি ব্যবহার করে প্রয়োগ করা হয়।

ফুলস্ক্রিন ইন্টেন্টের জন্য অনুমতি পরিবর্তন

যেসব অ্যাপ অ্যান্ড্রয়েড ১০ বা তার উচ্চতর সংস্করণকে টার্গেট করে এবং ফুলস্ক্রিন ইন্টেন্টের মাধ্যমে নোটিফিকেশন ব্যবহার করে, তাদের অ্যাপের ম্যানিফেস্ট ফাইলে অবশ্যই USE_FULL_SCREEN_INTENT পারমিশনের জন্য অনুরোধ করতে হবে। এটি একটি সাধারণ পারমিশন , তাই সিস্টেম স্বয়ংক্রিয়ভাবে অনুরোধকারী অ্যাপটিকে এটি মঞ্জুর করে।

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

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

ফোল্ডেবলের জন্য সমর্থন

অ্যান্ড্রয়েড ১০-এ এমন কিছু পরিবর্তন আনা হয়েছে যা ফোল্ডেবল ও বড় স্ক্রিনের ডিভাইসগুলোকে সাপোর্ট করে।

যখন কোনো অ্যাপ অ্যান্ড্রয়েড ১০-এ চলে, তখন onResume() এবং onPause() মেথডগুলো ভিন্নভাবে কাজ করে। যখন মাল্টি-উইন্ডো বা মাল্টি-ডিসপ্লে মোডে একই সময়ে একাধিক অ্যাপ দেখা যায়, তখন দৃশ্যমান স্ট্যাকের মধ্যে থাকা ফোকাসযোগ্য সব টপ অ্যাক্টিভিটি 'রিজিউমড' অবস্থায় থাকে, কিন্তু সেগুলোর মধ্যে শুধুমাত্র একটি, অর্থাৎ 'সবচেয়ে উপরের রিজিউমড' অ্যাক্টিভিটিটিই প্রকৃতপক্ষে ফোকাস পায়। অ্যান্ড্রয়েড ১০-এর আগের সংস্করণগুলোতে চলার সময়, সিস্টেমের শুধুমাত্র একটি অ্যাক্টিভিটি একবারে রিজিউম করা যেত এবং অন্য সব দৃশ্যমান অ্যাক্টিভিটি 'পজড' থাকত।

'ফোকাস' এবং 'সর্বাধিক পুনরায় চালু হওয়া' অ্যাক্টিভিটিকে গুলিয়ে ফেলবেন না। সিস্টেম z-order অনুসারে অ্যাক্টিভিটিগুলোকে অগ্রাধিকার দেয়, যাতে ব্যবহারকারী সর্বশেষ যে অ্যাক্টিভিটিগুলোর সাথে ইন্টারঅ্যাক্ট করেছেন সেগুলোকে উচ্চতর অগ্রাধিকার দেওয়া হয়। একটি অ্যাক্টিভিটি টপ-রিজিউমড হতে পারে, কিন্তু সেটিতে ফোকাস নাও থাকতে পারে (উদাহরণস্বরূপ, যদি নোটিফিকেশন শেডটি প্রসারিত থাকে)।

অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) এবং এর পরবর্তী সংস্করণগুলোতে, আপনার অ্যাক্টিভিটি যখন সর্বোচ্চ রিজুমড অবস্থান অর্জন করে বা হারায়, তখন বিজ্ঞপ্তি পাওয়ার জন্য আপনি onTopResumedActivityChanged() কলব্যাকে সাবস্ক্রাইব করতে পারেন। এটি অ্যান্ড্রয়েড ১০-এর আগের রিজুমড অবস্থার সমতুল্য এবং আপনার অ্যাপ যদি এমন এক্সক্লুসিভ বা সিঙ্গেলটন রিসোর্স ব্যবহার করে যা অন্য অ্যাপের সাথে শেয়ার করার প্রয়োজন হতে পারে, তবে এটি একটি ইঙ্গিত হিসেবে কার্যকর হতে পারে।

resizeableActivity ম্যানিফেস্ট অ্যাট্রিবিউটের আচরণেও পরিবর্তন এসেছে। অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) বা তার পরবর্তী সংস্করণে, যদি কোনো অ্যাপ resizeableActivity=false সেট করে, তাহলে উপলব্ধ স্ক্রিনের আকার পরিবর্তিত হলে বা অ্যাপটি এক স্ক্রিন থেকে অন্য স্ক্রিনে গেলে সেটি কম্প্যাটিবিলিটি মোডে চলে যেতে পারে।

আপনার অ্যাপটি কোন কোন স্ক্রিন রেশিও সাপোর্ট করে, তা নির্দেশ করার জন্য অ্যাপগুলো অ্যান্ড্রয়েড ১০-এ প্রবর্তিত android:minAspectRatio অ্যাট্রিবিউটটি ব্যবহার করতে পারে।

সংস্করণ ৩.৫ থেকে শুরু করে, অ্যান্ড্রয়েড স্টুডিওর এমুলেটর টুলে বড় স্ক্রিনে আপনার কোড পরীক্ষা করার জন্য ৭.৩" এবং ৮" ভার্চুয়াল ডিভাইস অন্তর্ভুক্ত করা হয়েছে।

আরও তথ্যের জন্য, ফোল্ডেবল ডিভাইসের জন্য আপনার অ্যাপ ডিজাইন করুন দেখুন।