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

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

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

নন-SDK ইন্টারফেস বিধিনিষেধের আপডেট

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

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

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

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

ভাগ করা মেমোরি

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

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

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

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

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

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

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

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

শিল্পকলায় AOT সঠিকতা প্রয়োগ করা

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

• কাস্টম ক্লাস লোডার—অর্থাৎ, 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-ক্রমের ভিত্তিতে কার্যকলাপের অগ্রাধিকার নির্ধারণ করে। একটি কার্যকলাপ শীর্ষ-পুনঃসূচনা করা যেতে পারে, কিন্তু ফোকাস করা যাবে না (উদাহরণস্বরূপ, যদি বিজ্ঞপ্তির ছায়া প্রসারিত করা হয়)।

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

resizeableActivity ম্যানিফেস্ট অ্যাট্রিবিউটের আচরণও পরিবর্তিত হয়েছে। যদি কোনও অ্যাপ Android 10 (API লেভেল 29) বা তার পরবর্তী সংস্করণে resizeableActivity=false সেট করে, তাহলে উপলব্ধ স্ক্রিনের আকার পরিবর্তন হলে, অথবা অ্যাপটি এক স্ক্রিন থেকে অন্য স্ক্রিনে সরে গেলে এটি সামঞ্জস্যতা মোডে রাখা হতে পারে।

আপনার অ্যাপ কোন স্ক্রিন রেশিও সমর্থন করে তা নির্দেশ করতে, অ্যাপগুলি Android 10-এ প্রবর্তিত android:minAspectRatio অ্যাট্রিবিউট ব্যবহার করতে পারে।

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

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