অ্যান্ড্রয়েড 10 আপডেট করা সিস্টেম আচরণ পরিবর্তনগুলি অন্তর্ভুক্ত করে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি শুধুমাত্র API 29 বা উচ্চতর টার্গেট করা অ্যাপগুলিতে প্রযোজ্য৷ যদি আপনার অ্যাপ targetSdkVersion "29" বা উচ্চতর সেট করে, তাহলে এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনার অ্যাপটি সংশোধন করা উচিত, যেখানে প্রযোজ্য।
অ্যান্ড্রয়েড 10 এ চলমান সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণের পরিবর্তনগুলির তালিকাটিও পর্যালোচনা করা নিশ্চিত করুন।
দ্রষ্টব্য: এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি ছাড়াও, Android 10 নিম্নলিখিতগুলি সহ প্রচুর পরিমাণে গোপনীয়তা-ভিত্তিক পরিবর্তন এবং বিধিনিষেধ প্রবর্তন করে:
- স্কোপড স্টোরেজ
- ইউএসবি ডিভাইস সিরিয়াল নম্বর অ্যাক্সেস
- Wi-Fi সক্ষম, অক্ষম এবং কনফিগার করার ক্ষমতা
- সংযোগ API-এর জন্য অবস্থানের অনুমতি
এই পরিবর্তনগুলি, যা এপিআই লেভেল 29 বা তার উপরে লক্ষ্য করে এমন অ্যাপগুলিকে প্রভাবিত করে, ব্যবহারকারীর গোপনীয়তা বাড়ায়। এই পরিবর্তনগুলিকে কীভাবে সমর্থন করবেন সে সম্পর্কে আরও জানতে, গোপনীয়তা পরিবর্তন পৃষ্ঠাটি দেখুন।
নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেট
অ্যাপের স্থিতিশীলতা এবং সামঞ্জস্যতা নিশ্চিত করতে সাহায্য করার জন্য, প্ল্যাটফর্মটি Android 9 (API স্তর 28) এ আপনার অ্যাপ ব্যবহার করতে পারে এমন নন-SDK ইন্টারফেসগুলিকে সীমাবদ্ধ করা শুরু করেছে। Android 10-এ Android বিকাশকারীদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। আমাদের লক্ষ্য হল আমরা নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে তা নিশ্চিত করা।
আপনি যদি Android 10 (API লেভেল 29) টার্গেট না করেন তবে এই পরিবর্তনগুলির মধ্যে কিছু আপনাকে অবিলম্বে প্রভাবিত করতে পারে না। যাইহোক, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে ), যেকোন নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে সবসময় আপনার অ্যাপ ভাঙার উচ্চ ঝুঁকি থাকে।
আপনি যদি নিশ্চিত না হন যে আপনার অ্যাপ নন-SDK ইন্টারফেস ব্যবহার করে, তাহলে আপনি খুঁজে বের করতে আপনার অ্যাপ পরীক্ষা করতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে স্থানান্তরের পরিকল্পনা শুরু করা উচিত। তা সত্ত্বেও, আমরা বুঝি যে কিছু অ্যাপে নন-SDK ইন্টারফেস ব্যবহার করার জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। আপনি যদি আপনার অ্যাপে একটি বৈশিষ্ট্যের জন্য একটি নন-SDK ইন্টারফেস ব্যবহার করার বিকল্প খুঁজে না পান তবে আপনাকে একটি নতুন সর্বজনীন API অনুরোধ করা উচিত।
আরও জানতে, Android 10-এ নন-SDK ইন্টারফেস বিধিনিষেধের আপডেট দেখুন এবং নন-SDK ইন্টারফেসে সীমাবদ্ধতা দেখুন।
শেয়ার করা মেমরি
Ashmem /proc/<pid>/maps-এ ডালভিক মানচিত্রের বিন্যাস পরিবর্তন করেছে, যা ম্যাপ ফাইলকে সরাসরি পার্স করে এমন অ্যাপগুলিকে প্রভাবিত করে। অ্যাপ্লিকেশান বিকাশকারীদের /proc/<pid>/maps ফরম্যাট পরীক্ষা করা উচিত যেগুলি Android 10 বা উচ্চতর চালায় এবং অ্যাপটি ডালভিক মানচিত্র ফর্ম্যাটের উপর নির্ভর করে সেই অনুযায়ী পার্স করুন৷
Android 10 টার্গেট করা অ্যাপগুলি সরাসরি ashmem (/dev/ashmem) ব্যবহার করতে পারে না এবং পরিবর্তে NDK-এর ASharedMemory ক্লাসের মাধ্যমে শেয়ার করা মেমরি অ্যাক্সেস করতে হবে। উপরন্তু, অ্যাপগুলি বিদ্যমান অ্যাশমেম ফাইল বর্ণনাকারীদের সরাসরি IOCTL তৈরি করতে পারে না এবং এর পরিবর্তে শেয়ার করা মেমরি অঞ্চল তৈরির জন্য NDK-এর ASharedMemory ক্লাস বা Android Java API ব্যবহার করতে হবে। শেয়ার্ড মেমরির সাথে কাজ করার সময় এই পরিবর্তন নিরাপত্তা এবং দৃঢ়তা বাড়ায়, সামগ্রিকভাবে Android এর কর্মক্ষমতা এবং নিরাপত্তা উন্নত করে।
অ্যাপ হোম ডিরেক্টরির জন্য এক্সিকিউট অনুমতি সরানো হয়েছে
লিখনযোগ্য অ্যাপ হোম ডিরেক্টরি থেকে ফাইলগুলি সম্পাদন করা একটি W^X লঙ্ঘন । অ্যাপগুলির শুধুমাত্র বাইনারি কোড লোড করা উচিত যা একটি অ্যাপের APK ফাইলের মধ্যে এমবেড করা আছে।
Android 10 টার্গেট করে এমন অবিশ্বস্ত অ্যাপগুলি অ্যাপের হোম ডিরেক্টরির মধ্যে থাকা ফাইলগুলিতে সরাসরি execve() চালু করতে পারে না।
উপরন্তু, যে অ্যাপগুলি Android 10 কে লক্ষ্য করে সেগুলি dlopen() দিয়ে খোলা ফাইলগুলি থেকে এক্সিকিউটেবল কোড ইন-মেমরি পরিবর্তন করতে পারে না এবং সেই পরিবর্তনগুলি ডিস্কের মাধ্যমে লেখার আশা করে, কারণ লাইব্রেরিটি একটি লিখনযোগ্য ফাইল বর্ণনাকারীর মাধ্যমে PROT_EXEC ম্যাপ করা যায় না। এতে টেক্সট রিলোকেশন সহ যেকোনও শেয়ার করা অবজেক্ট ( .so ) ফাইল অন্তর্ভুক্ত থাকে।
অ্যান্ড্রয়েড রানটাইম শুধুমাত্র সিস্টেম-জেনারেটেড OAT ফাইল গ্রহণ করে
অ্যান্ড্রয়েড রানটাইম (ART) আর আবেদন প্রক্রিয়া থেকে dex2oat ব্যবহার করে না। এই পরিবর্তনের মানে হল যে ART শুধুমাত্র OAT ফাইলগুলি গ্রহণ করবে যা সিস্টেম তৈরি করেছে।
ART এ AOT সঠিকতা প্রয়োগ করা
অতীতে, অ্যান্ড্রয়েড রানটাইম (এআরটি) দ্বারা সম্পাদিত অগ্র-অফ-টাইম (AOT) সংকলনটি রানটাইম ক্র্যাশের কারণ হতে পারে যদি কম্পাইল টাইম এবং রানটাইমে ক্লাসপথের পরিবেশ একই না হয়। অ্যান্ড্রয়েড 10 এবং উচ্চতরের জন্য সর্বদা এই পরিবেশের প্রসঙ্গগুলি একই হওয়া প্রয়োজন, যার ফলে আচরণে নিম্নলিখিত পরিবর্তনগুলি ঘটে:
- কাস্টম ক্লাস লোডার—অর্থাৎ, অ্যাপ দ্বারা লেখা ক্লাস লোডার,
dalvik.systemপ্যাকেজের ক্লাস লোডারের বিপরীতে—এওটি-সংকলিত হয় না। কারণ রানটাইমে কাস্টমাইজড ক্লাস লুকআপ বাস্তবায়ন সম্পর্কে ART জানতে পারে না। - সেকেন্ডারি ডেক্স ফাইল—অর্থাৎ, প্রাথমিক APK-এ নেই এমন অ্যাপের মাধ্যমে ম্যানুয়ালি লোড করা ডেক্স ফাইলগুলি-ব্যাকগ্রাউন্ডে AOT-সংকলিত। এর কারণ হল প্রথম-ব্যবহারের সংকলন খুব ব্যয়বহুল হতে পারে, যা কার্যকর করার আগে অবাঞ্ছিত বিলম্বের দিকে পরিচালিত করে। মনে রাখবেন যে অ্যাপগুলির জন্য, স্প্লিটগুলি গ্রহণ করা এবং সেকেন্ডারি ডেক্স ফাইলগুলি থেকে দূরে সরে যাওয়ার পরামর্শ দেওয়া হয়।
- অ্যান্ড্রয়েডের শেয়ার্ড লাইব্রেরিগুলি (একটি অ্যান্ড্রয়েড ম্যানিফেস্টে <লাইব্রেরি> এবং <ব্যবহার-লাইব্রেরি> এন্ট্রি) প্লাটফর্মের পূর্ববর্তী সংস্করণগুলিতে ব্যবহৃত একটি থেকে ভিন্ন শ্রেণির লোডার শ্রেণিবিন্যাস ব্যবহার করে প্রয়োগ করা হয়।
পূর্ণস্ক্রীন অভিপ্রায় জন্য অনুমতি পরিবর্তন
যে অ্যাপগুলি Android 10 বা তার বেশির দিকে লক্ষ্য করে এবং ফুলস্ক্রিন ইন্টেন্ট সহ বিজ্ঞপ্তিগুলি ব্যবহার করে তাদের অবশ্যই তাদের অ্যাপের ম্যানিফেস্ট ফাইলে USE_FULL_SCREEN_INTENT অনুমতির অনুরোধ করতে হবে। এটি একটি স্বাভাবিক অনুমতি , তাই সিস্টেম স্বয়ংক্রিয়ভাবে অনুরোধকারী অ্যাপে এটি মঞ্জুর করে।
যদি কোনো অ্যাপ যেটি Android 10 বা উচ্চতরকে লক্ষ্য করে তা প্রয়োজনীয় অনুমতির অনুরোধ ছাড়াই একটি পূর্ণস্ক্রীন অভিপ্রায় সহ একটি বিজ্ঞপ্তি তৈরি করার চেষ্টা করে, সিস্টেমটি ফুলস্ক্রিন অভিপ্রায় উপেক্ষা করে এবং নিম্নলিখিত লগ বার্তাটি আউটপুট করে:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Foldables জন্য সমর্থন
অ্যান্ড্রয়েড 10-এ এমন পরিবর্তন রয়েছে যা ফোল্ডেবল এবং বড় স্ক্রিনের ডিভাইসগুলিকে সমর্থন করে।
যখন একটি অ্যাপ অ্যান্ড্রয়েড 10 এ চলে, তখন onResume() এবং onPause() পদ্ধতি ভিন্নভাবে কাজ করে। মাল্টি-উইন্ডো বা মাল্টি-ডিসপ্লে মোডে একই সময়ে একাধিক অ্যাপ উপস্থিত হলে, দৃশ্যমান স্ট্যাকের সমস্ত ফোকাসযোগ্য শীর্ষ ক্রিয়াকলাপগুলি পুনঃসূচনা অবস্থায় থাকে, কিন্তু তাদের মধ্যে শুধুমাত্র একটি, "সর্বোচ্চ পুনঃসূচনা" কার্যকলাপে আসলে ফোকাস থাকে৷ অ্যান্ড্রয়েড 10-এর আগের সংস্করণে চলাকালীন, সিস্টেমে শুধুমাত্র একটি একক কার্যকলাপ একবারে পুনরায় শুরু করা যেতে পারে, অন্যান্য সমস্ত দৃশ্যমান ক্রিয়াকলাপ বিরাম দেওয়া হয়।
"সর্বোচ্চ পুনঃসূচনা" কার্যকলাপের সাথে "ফোকাস" কে বিভ্রান্ত করবেন না। সিস্টেমটি z-অর্ডারের উপর ভিত্তি করে ক্রিয়াকলাপের জন্য অগ্রাধিকার নির্ধারণ করে যাতে ব্যবহারকারী সর্বশেষ যে সমস্ত ক্রিয়াকলাপের সাথে ইন্টারঅ্যাক্ট করেছিল সেগুলিকে উচ্চতর অগ্রাধিকার দিতে। একটি ক্রিয়াকলাপ শীর্ষ-পুনরায় শুরু করা যেতে পারে, তবে ফোকাস নেই (উদাহরণস্বরূপ, যদি বিজ্ঞপ্তি ছায়া প্রসারিত হয়)।
Android 10 (API লেভেল 29) এবং পরবর্তীতে, আপনি onTopResumedActivityChanged() কলব্যাকে সাবস্ক্রাইব করতে পারেন যখন আপনার অ্যাক্টিভিটি শীর্ষস্থানীয় পুনঃসূচনা অবস্থান অর্জন করে বা হারায় তখন বিজ্ঞপ্তি পাওয়ার জন্য। এটি অ্যান্ড্রয়েড 10-এর আগে পুনরায় শুরু হওয়া অবস্থার সমতুল্য এবং আপনার অ্যাপ যদি এক্সক্লুসিভ বা সিঙ্গলটন রিসোর্স ব্যবহার করে থাকে যা অন্য অ্যাপের সাথে শেয়ার করার প্রয়োজন হতে পারে তাহলে এটি একটি ইঙ্গিত হিসেবে উপযোগী হতে পারে।
resizeableActivity ম্যানিফেস্ট অ্যাট্রিবিউটের আচরণও পরিবর্তিত হয়েছে। যদি কোনও অ্যাপ Android 10 (API লেভেল 29) বা তার পরে resizeableActivity=false সেট করে, তাহলে উপলব্ধ স্ক্রীনের আকার পরিবর্তন হলে বা অ্যাপটি এক স্ক্রীন থেকে অন্য স্ক্রীনে চলে গেলে এটি সামঞ্জস্যপূর্ণ মোডে রাখা হতে পারে।
অ্যাপ্লিকেশানগুলি আপনার অ্যাপ সমর্থন করে এমন স্ক্রিন অনুপাত নির্দেশ করতে Android 10-এ প্রবর্তিত android:minAspectRatio অ্যাট্রিবিউট ব্যবহার করতে পারে৷
সংস্করণ 3.5 থেকে শুরু করে, অ্যান্ড্রয়েড স্টুডিওর এমুলেটর টুলে 7.3" এবং 8" ভার্চুয়াল ডিভাইস রয়েছে যাতে বড় স্ক্রীনে আপনার কোড পরীক্ষা করা যায়।
আরও তথ্যের জন্য, ফোল্ডেবলের জন্য আপনার অ্যাপস ডিজাইন দেখুন।
, অ্যান্ড্রয়েড 10 আপডেট করা সিস্টেম আচরণ পরিবর্তনগুলি অন্তর্ভুক্ত করে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি শুধুমাত্র API 29 বা উচ্চতর টার্গেট করা অ্যাপগুলিতে প্রযোজ্য৷ যদি আপনার অ্যাপ targetSdkVersion "29" বা উচ্চতর সেট করে, তাহলে এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনার অ্যাপটি সংশোধন করা উচিত, যেখানে প্রযোজ্য।
অ্যান্ড্রয়েড 10 এ চলমান সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণের পরিবর্তনগুলির তালিকাটিও পর্যালোচনা করা নিশ্চিত করুন।
দ্রষ্টব্য: এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি ছাড়াও, Android 10 নিম্নলিখিতগুলি সহ প্রচুর পরিমাণে গোপনীয়তা-ভিত্তিক পরিবর্তন এবং বিধিনিষেধ প্রবর্তন করে:
- স্কোপড স্টোরেজ
- ইউএসবি ডিভাইস সিরিয়াল নম্বর অ্যাক্সেস
- Wi-Fi সক্ষম, অক্ষম এবং কনফিগার করার ক্ষমতা
- সংযোগ API-এর জন্য অবস্থানের অনুমতি
এই পরিবর্তনগুলি, যা এপিআই লেভেল 29 বা তার উপরে লক্ষ্য করে এমন অ্যাপগুলিকে প্রভাবিত করে, ব্যবহারকারীর গোপনীয়তা বাড়ায়। এই পরিবর্তনগুলিকে কীভাবে সমর্থন করবেন সে সম্পর্কে আরও জানতে, গোপনীয়তা পরিবর্তন পৃষ্ঠাটি দেখুন।
নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেট
অ্যাপের স্থিতিশীলতা এবং সামঞ্জস্যতা নিশ্চিত করতে সাহায্য করার জন্য, প্ল্যাটফর্মটি Android 9 (API স্তর 28) এ আপনার অ্যাপ ব্যবহার করতে পারে এমন নন-SDK ইন্টারফেসগুলিকে সীমাবদ্ধ করা শুরু করেছে। Android 10-এ Android বিকাশকারীদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। আমাদের লক্ষ্য হল আমরা নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে তা নিশ্চিত করা।
আপনি যদি Android 10 (API লেভেল 29) টার্গেট না করেন তবে এই পরিবর্তনগুলির মধ্যে কিছু আপনাকে অবিলম্বে প্রভাবিত করতে পারে না। যাইহোক, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে ), যেকোন নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে সবসময় আপনার অ্যাপ ভাঙার উচ্চ ঝুঁকি থাকে।
আপনি যদি নিশ্চিত না হন যে আপনার অ্যাপ নন-SDK ইন্টারফেস ব্যবহার করে, তাহলে আপনি খুঁজে বের করতে আপনার অ্যাপ পরীক্ষা করতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে স্থানান্তরের পরিকল্পনা শুরু করা উচিত। তা সত্ত্বেও, আমরা বুঝি যে কিছু অ্যাপে নন-SDK ইন্টারফেস ব্যবহার করার জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। আপনি যদি আপনার অ্যাপে একটি বৈশিষ্ট্যের জন্য একটি নন-SDK ইন্টারফেস ব্যবহার করার বিকল্প খুঁজে না পান তবে আপনাকে একটি নতুন সর্বজনীন API অনুরোধ করা উচিত।
আরও জানতে, Android 10-এ নন-SDK ইন্টারফেস বিধিনিষেধের আপডেট দেখুন এবং নন-SDK ইন্টারফেসে সীমাবদ্ধতা দেখুন।
শেয়ার করা মেমরি
Ashmem /proc/<pid>/maps-এ ডালভিক মানচিত্রের বিন্যাস পরিবর্তন করেছে, যা ম্যাপ ফাইলকে সরাসরি পার্স করে এমন অ্যাপগুলিকে প্রভাবিত করে। অ্যাপ্লিকেশান বিকাশকারীদের /proc/<pid>/maps ফরম্যাট পরীক্ষা করা উচিত যেগুলি Android 10 বা উচ্চতর চালায় এবং অ্যাপটি ডালভিক মানচিত্র ফর্ম্যাটের উপর নির্ভর করে সেই অনুযায়ী পার্স করুন৷
Android 10 টার্গেট করা অ্যাপগুলি সরাসরি ashmem (/dev/ashmem) ব্যবহার করতে পারে না এবং পরিবর্তে NDK-এর ASharedMemory ক্লাসের মাধ্যমে শেয়ার করা মেমরি অ্যাক্সেস করতে হবে। উপরন্তু, অ্যাপগুলি বিদ্যমান অ্যাশমেম ফাইল বর্ণনাকারীদের সরাসরি IOCTL তৈরি করতে পারে না এবং এর পরিবর্তে শেয়ার করা মেমরি অঞ্চল তৈরির জন্য NDK-এর ASharedMemory ক্লাস বা Android Java API ব্যবহার করতে হবে। শেয়ার্ড মেমরির সাথে কাজ করার সময় এই পরিবর্তন নিরাপত্তা এবং দৃঢ়তা বাড়ায়, সামগ্রিকভাবে Android এর কর্মক্ষমতা এবং নিরাপত্তা উন্নত করে।
অ্যাপ হোম ডিরেক্টরির জন্য এক্সিকিউট অনুমতি সরানো হয়েছে
লিখনযোগ্য অ্যাপ হোম ডিরেক্টরি থেকে ফাইলগুলি সম্পাদন করা একটি W^X লঙ্ঘন । অ্যাপগুলির শুধুমাত্র বাইনারি কোড লোড করা উচিত যা একটি অ্যাপের APK ফাইলের মধ্যে এমবেড করা আছে।
Android 10 টার্গেট করে এমন অবিশ্বস্ত অ্যাপগুলি অ্যাপের হোম ডিরেক্টরির মধ্যে থাকা ফাইলগুলিতে সরাসরি execve() চালু করতে পারে না।
উপরন্তু, যে অ্যাপগুলি Android 10 কে লক্ষ্য করে সেগুলি dlopen() দিয়ে খোলা ফাইলগুলি থেকে এক্সিকিউটেবল কোড ইন-মেমরি পরিবর্তন করতে পারে না এবং সেই পরিবর্তনগুলি ডিস্কের মাধ্যমে লেখার আশা করে, কারণ লাইব্রেরিটি একটি লিখনযোগ্য ফাইল বর্ণনাকারীর মাধ্যমে PROT_EXEC ম্যাপ করা যায় না। এতে টেক্সট রিলোকেশন সহ যেকোনও শেয়ার করা অবজেক্ট ( .so ) ফাইল অন্তর্ভুক্ত থাকে।
অ্যান্ড্রয়েড রানটাইম শুধুমাত্র সিস্টেম-জেনারেটেড OAT ফাইল গ্রহণ করে
অ্যান্ড্রয়েড রানটাইম (ART) আর আবেদন প্রক্রিয়া থেকে dex2oat ব্যবহার করে না। এই পরিবর্তনের মানে হল যে ART শুধুমাত্র OAT ফাইলগুলি গ্রহণ করবে যা সিস্টেম তৈরি করেছে।
ART এ AOT সঠিকতা প্রয়োগ করা
অতীতে, অ্যান্ড্রয়েড রানটাইম (এআরটি) দ্বারা সম্পাদিত অগ্র-অফ-টাইম (AOT) সংকলনটি রানটাইম ক্র্যাশের কারণ হতে পারে যদি কম্পাইল টাইম এবং রানটাইমে ক্লাসপথের পরিবেশ একই না হয়। অ্যান্ড্রয়েড 10 এবং উচ্চতরের জন্য সর্বদা এই পরিবেশের প্রসঙ্গগুলি একই হওয়া প্রয়োজন, যার ফলে আচরণে নিম্নলিখিত পরিবর্তনগুলি ঘটে:
- কাস্টম ক্লাস লোডার—অর্থাৎ, অ্যাপ দ্বারা লেখা ক্লাস লোডার,
dalvik.systemপ্যাকেজের ক্লাস লোডারের বিপরীতে—এওটি-সংকলিত হয় না। কারণ রানটাইমে কাস্টমাইজড ক্লাস লুকআপ বাস্তবায়ন সম্পর্কে ART জানতে পারে না। - সেকেন্ডারি ডেক্স ফাইল—অর্থাৎ, প্রাথমিক APK-এ নেই এমন অ্যাপের মাধ্যমে ম্যানুয়ালি লোড করা ডেক্স ফাইলগুলি-ব্যাকগ্রাউন্ডে AOT-সংকলিত। এর কারণ হল প্রথম-ব্যবহারের সংকলন খুব ব্যয়বহুল হতে পারে, যা কার্যকর করার আগে অবাঞ্ছিত বিলম্বের দিকে পরিচালিত করে। মনে রাখবেন যে অ্যাপগুলির জন্য, স্প্লিটগুলি গ্রহণ করা এবং সেকেন্ডারি ডেক্স ফাইলগুলি থেকে দূরে সরে যাওয়ার পরামর্শ দেওয়া হয়।
- অ্যান্ড্রয়েডের শেয়ার্ড লাইব্রেরিগুলি (একটি অ্যান্ড্রয়েড ম্যানিফেস্টে <লাইব্রেরি> এবং <ব্যবহার-লাইব্রেরি> এন্ট্রি) প্লাটফর্মের পূর্ববর্তী সংস্করণগুলিতে ব্যবহৃত একটি থেকে ভিন্ন শ্রেণির লোডার শ্রেণিবিন্যাস ব্যবহার করে প্রয়োগ করা হয়।
পূর্ণস্ক্রীন অভিপ্রায় জন্য অনুমতি পরিবর্তন
যে অ্যাপগুলি Android 10 বা তার বেশির দিকে লক্ষ্য করে এবং ফুলস্ক্রিন ইন্টেন্ট সহ বিজ্ঞপ্তিগুলি ব্যবহার করে তাদের অবশ্যই তাদের অ্যাপের ম্যানিফেস্ট ফাইলে USE_FULL_SCREEN_INTENT অনুমতির অনুরোধ করতে হবে। এটি একটি স্বাভাবিক অনুমতি , তাই সিস্টেম স্বয়ংক্রিয়ভাবে অনুরোধকারী অ্যাপে এটি মঞ্জুর করে।
যদি কোনো অ্যাপ যেটি Android 10 বা উচ্চতরকে লক্ষ্য করে তা প্রয়োজনীয় অনুমতির অনুরোধ ছাড়াই একটি পূর্ণস্ক্রীন অভিপ্রায় সহ একটি বিজ্ঞপ্তি তৈরি করার চেষ্টা করে, সিস্টেমটি ফুলস্ক্রিন অভিপ্রায় উপেক্ষা করে এবং নিম্নলিখিত লগ বার্তাটি আউটপুট করে:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Foldables জন্য সমর্থন
অ্যান্ড্রয়েড 10-এ এমন পরিবর্তন রয়েছে যা ফোল্ডেবল এবং বড় স্ক্রিনের ডিভাইসগুলিকে সমর্থন করে।
যখন একটি অ্যাপ অ্যান্ড্রয়েড 10 এ চলে, তখন onResume() এবং onPause() পদ্ধতি ভিন্নভাবে কাজ করে। মাল্টি-উইন্ডো বা মাল্টি-ডিসপ্লে মোডে একই সময়ে একাধিক অ্যাপ উপস্থিত হলে, দৃশ্যমান স্ট্যাকের সমস্ত ফোকাসযোগ্য শীর্ষ ক্রিয়াকলাপগুলি পুনঃসূচনা অবস্থায় থাকে, কিন্তু তাদের মধ্যে শুধুমাত্র একটি, "সর্বোচ্চ পুনঃসূচনা" কার্যকলাপে আসলে ফোকাস থাকে৷ অ্যান্ড্রয়েড 10-এর আগের সংস্করণে চলাকালীন, সিস্টেমে শুধুমাত্র একটি একক কার্যকলাপ একবারে পুনরায় শুরু করা যেতে পারে, অন্যান্য সমস্ত দৃশ্যমান ক্রিয়াকলাপ বিরাম দেওয়া হয়।
"সর্বোচ্চ পুনঃসূচনা" কার্যকলাপের সাথে "ফোকাস" কে বিভ্রান্ত করবেন না। সিস্টেমটি z-অর্ডারের উপর ভিত্তি করে ক্রিয়াকলাপের জন্য অগ্রাধিকার নির্ধারণ করে যাতে ব্যবহারকারী সর্বশেষ যে সমস্ত ক্রিয়াকলাপের সাথে ইন্টারঅ্যাক্ট করেছিল সেগুলিকে উচ্চতর অগ্রাধিকার দিতে। একটি ক্রিয়াকলাপ শীর্ষ-পুনরায় শুরু করা যেতে পারে, তবে ফোকাস নেই (উদাহরণস্বরূপ, যদি বিজ্ঞপ্তি ছায়া প্রসারিত হয়)।
Android 10 (API লেভেল 29) এবং পরবর্তীতে, আপনি onTopResumedActivityChanged() কলব্যাকে সাবস্ক্রাইব করতে পারেন যখন আপনার অ্যাক্টিভিটি শীর্ষস্থানীয় পুনঃসূচনা অবস্থান অর্জন করে বা হারায় তখন বিজ্ঞপ্তি পাওয়ার জন্য। এটি অ্যান্ড্রয়েড 10-এর আগে পুনরায় শুরু হওয়া অবস্থার সমতুল্য এবং আপনার অ্যাপ যদি এক্সক্লুসিভ বা সিঙ্গলটন রিসোর্স ব্যবহার করে থাকে যা অন্য অ্যাপের সাথে শেয়ার করার প্রয়োজন হতে পারে তাহলে এটি একটি ইঙ্গিত হিসেবে উপযোগী হতে পারে।
resizeableActivity ম্যানিফেস্ট অ্যাট্রিবিউটের আচরণও পরিবর্তিত হয়েছে। যদি কোনও অ্যাপ Android 10 (API লেভেল 29) বা তার পরে resizeableActivity=false সেট করে, তাহলে উপলব্ধ স্ক্রীনের আকার পরিবর্তন হলে বা অ্যাপটি এক স্ক্রীন থেকে অন্য স্ক্রীনে চলে গেলে এটি সামঞ্জস্যপূর্ণ মোডে রাখা হতে পারে।
অ্যাপ্লিকেশানগুলি আপনার অ্যাপ সমর্থন করে এমন স্ক্রিন অনুপাত নির্দেশ করতে Android 10-এ প্রবর্তিত android:minAspectRatio অ্যাট্রিবিউট ব্যবহার করতে পারে৷
সংস্করণ 3.5 থেকে শুরু করে, অ্যান্ড্রয়েড স্টুডিওর এমুলেটর টুলে 7.3" এবং 8" ভার্চুয়াল ডিভাইস রয়েছে যাতে বড় স্ক্রীনে আপনার কোড পরীক্ষা করা যায়।
আরও তথ্যের জন্য, ফোল্ডেবলের জন্য আপনার অ্যাপস ডিজাইন দেখুন।
, অ্যান্ড্রয়েড 10 আপডেট করা সিস্টেম আচরণ পরিবর্তনগুলি অন্তর্ভুক্ত করে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি শুধুমাত্র API 29 বা উচ্চতর টার্গেট করা অ্যাপগুলিতে প্রযোজ্য৷ যদি আপনার অ্যাপ targetSdkVersion "29" বা উচ্চতর সেট করে, তাহলে এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনার অ্যাপটি সংশোধন করা উচিত, যেখানে প্রযোজ্য।
অ্যান্ড্রয়েড 10 এ চলমান সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণের পরিবর্তনগুলির তালিকাটিও পর্যালোচনা করা নিশ্চিত করুন।
দ্রষ্টব্য: এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি ছাড়াও, Android 10 নিম্নলিখিতগুলি সহ প্রচুর পরিমাণে গোপনীয়তা-ভিত্তিক পরিবর্তন এবং বিধিনিষেধ প্রবর্তন করে:
- স্কোপড স্টোরেজ
- ইউএসবি ডিভাইস সিরিয়াল নম্বর অ্যাক্সেস
- Wi-Fi সক্ষম, অক্ষম এবং কনফিগার করার ক্ষমতা
- সংযোগ API-এর জন্য অবস্থানের অনুমতি
এই পরিবর্তনগুলি, যা এপিআই লেভেল 29 বা তার উপরে লক্ষ্য করে এমন অ্যাপগুলিকে প্রভাবিত করে, ব্যবহারকারীর গোপনীয়তা বাড়ায়। এই পরিবর্তনগুলিকে কীভাবে সমর্থন করবেন সে সম্পর্কে আরও জানতে, গোপনীয়তা পরিবর্তন পৃষ্ঠাটি দেখুন।
নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেট
অ্যাপের স্থিতিশীলতা এবং সামঞ্জস্যতা নিশ্চিত করতে সাহায্য করার জন্য, প্ল্যাটফর্মটি Android 9 (API স্তর 28) এ আপনার অ্যাপ ব্যবহার করতে পারে এমন নন-SDK ইন্টারফেসগুলিকে সীমাবদ্ধ করা শুরু করেছে। Android 10-এ Android বিকাশকারীদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। আমাদের লক্ষ্য হল আমরা নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে তা নিশ্চিত করা।
আপনি যদি Android 10 (API লেভেল 29) টার্গেট না করেন তবে এই পরিবর্তনগুলির মধ্যে কিছু আপনাকে অবিলম্বে প্রভাবিত করতে পারে না। যাইহোক, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে ), যেকোন নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে সবসময় আপনার অ্যাপ ভাঙার উচ্চ ঝুঁকি থাকে।
আপনি যদি নিশ্চিত না হন যে আপনার অ্যাপ নন-SDK ইন্টারফেস ব্যবহার করে, তাহলে আপনি খুঁজে বের করতে আপনার অ্যাপ পরীক্ষা করতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে স্থানান্তরের পরিকল্পনা শুরু করা উচিত। তা সত্ত্বেও, আমরা বুঝি যে কিছু অ্যাপে নন-SDK ইন্টারফেস ব্যবহার করার জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। আপনি যদি আপনার অ্যাপে একটি বৈশিষ্ট্যের জন্য একটি নন-SDK ইন্টারফেস ব্যবহার করার বিকল্প খুঁজে না পান তবে আপনাকে একটি নতুন সর্বজনীন API অনুরোধ করা উচিত।
আরও জানতে, Android 10-এ নন-SDK ইন্টারফেস বিধিনিষেধের আপডেট দেখুন এবং নন-SDK ইন্টারফেসে সীমাবদ্ধতা দেখুন।
শেয়ার করা মেমরি
Ashmem /proc/<pid>/maps-এ ডালভিক মানচিত্রের বিন্যাস পরিবর্তন করেছে, যা ম্যাপ ফাইলকে সরাসরি পার্স করে এমন অ্যাপগুলিকে প্রভাবিত করে। অ্যাপ্লিকেশান বিকাশকারীদের /proc/<pid>/maps ফরম্যাট পরীক্ষা করা উচিত যেগুলি Android 10 বা উচ্চতর চালায় এবং অ্যাপটি ডালভিক মানচিত্র ফর্ম্যাটের উপর নির্ভর করে সেই অনুযায়ী পার্স করুন৷
Android 10 টার্গেট করা অ্যাপগুলি সরাসরি ashmem (/dev/ashmem) ব্যবহার করতে পারে না এবং পরিবর্তে NDK-এর ASharedMemory ক্লাসের মাধ্যমে শেয়ার করা মেমরি অ্যাক্সেস করতে হবে। উপরন্তু, অ্যাপগুলি বিদ্যমান অ্যাশমেম ফাইল বর্ণনাকারীদের সরাসরি IOCTL তৈরি করতে পারে না এবং এর পরিবর্তে শেয়ার করা মেমরি অঞ্চল তৈরির জন্য NDK-এর ASharedMemory ক্লাস বা Android Java API ব্যবহার করতে হবে। শেয়ার্ড মেমরির সাথে কাজ করার সময় এই পরিবর্তন নিরাপত্তা এবং দৃঢ়তা বাড়ায়, সামগ্রিকভাবে Android এর কর্মক্ষমতা এবং নিরাপত্তা উন্নত করে।
অ্যাপ হোম ডিরেক্টরির জন্য এক্সিকিউট অনুমতি সরানো হয়েছে
লিখনযোগ্য অ্যাপ হোম ডিরেক্টরি থেকে ফাইলগুলি সম্পাদন করা একটি W^X লঙ্ঘন । অ্যাপগুলির শুধুমাত্র বাইনারি কোড লোড করা উচিত যা একটি অ্যাপের APK ফাইলের মধ্যে এমবেড করা আছে।
Android 10 টার্গেট করে এমন অবিশ্বস্ত অ্যাপগুলি অ্যাপের হোম ডিরেক্টরির মধ্যে থাকা ফাইলগুলিতে সরাসরি execve() চালু করতে পারে না।
উপরন্তু, যে অ্যাপগুলি Android 10 কে লক্ষ্য করে সেগুলি dlopen() দিয়ে খোলা ফাইলগুলি থেকে এক্সিকিউটেবল কোড ইন-মেমরি পরিবর্তন করতে পারে না এবং সেই পরিবর্তনগুলি ডিস্কের মাধ্যমে লেখার আশা করে, কারণ লাইব্রেরিটি একটি লিখনযোগ্য ফাইল বর্ণনাকারীর মাধ্যমে PROT_EXEC ম্যাপ করা যায় না। এতে টেক্সট রিলোকেশন সহ যেকোনও শেয়ার করা অবজেক্ট ( .so ) ফাইল অন্তর্ভুক্ত থাকে।
অ্যান্ড্রয়েড রানটাইম শুধুমাত্র সিস্টেম-জেনারেটেড OAT ফাইল গ্রহণ করে
অ্যান্ড্রয়েড রানটাইম (ART) আর আবেদন প্রক্রিয়া থেকে dex2oat ব্যবহার করে না। এই পরিবর্তনের মানে হল যে ART শুধুমাত্র OAT ফাইলগুলি গ্রহণ করবে যা সিস্টেম তৈরি করেছে।
ART এ AOT সঠিকতা প্রয়োগ করা
অতীতে, অ্যান্ড্রয়েড রানটাইম (এআরটি) দ্বারা সম্পাদিত অগ্র-অফ-টাইম (AOT) সংকলনটি রানটাইম ক্র্যাশের কারণ হতে পারে যদি কম্পাইল টাইম এবং রানটাইমে ক্লাসপথের পরিবেশ একই না হয়। অ্যান্ড্রয়েড 10 এবং উচ্চতরের জন্য সর্বদা এই পরিবেশের প্রসঙ্গগুলি একই হওয়া প্রয়োজন, যার ফলে আচরণে নিম্নলিখিত পরিবর্তনগুলি ঘটে:
- কাস্টম ক্লাস লোডার—অর্থাৎ, অ্যাপ দ্বারা লেখা ক্লাস লোডার,
dalvik.systemপ্যাকেজের ক্লাস লোডারের বিপরীতে—এওটি-সংকলিত হয় না। কারণ রানটাইমে কাস্টমাইজড ক্লাস লুকআপ বাস্তবায়ন সম্পর্কে ART জানতে পারে না। - সেকেন্ডারি ডেক্স ফাইল—অর্থাৎ, প্রাথমিক APK-এ নেই এমন অ্যাপের মাধ্যমে ম্যানুয়ালি লোড করা ডেক্স ফাইলগুলি-ব্যাকগ্রাউন্ডে AOT-সংকলিত। এর কারণ হল প্রথম-ব্যবহারের সংকলন খুব ব্যয়বহুল হতে পারে, যা কার্যকর করার আগে অবাঞ্ছিত বিলম্বের দিকে পরিচালিত করে। মনে রাখবেন যে অ্যাপগুলির জন্য, স্প্লিটগুলি গ্রহণ করা এবং সেকেন্ডারি ডেক্স ফাইলগুলি থেকে দূরে সরে যাওয়ার পরামর্শ দেওয়া হয়।
- অ্যান্ড্রয়েডের শেয়ার্ড লাইব্রেরিগুলি (একটি অ্যান্ড্রয়েড ম্যানিফেস্টে <লাইব্রেরি> এবং <ব্যবহার-লাইব্রেরি> এন্ট্রি) প্লাটফর্মের পূর্ববর্তী সংস্করণগুলিতে ব্যবহৃত একটি থেকে ভিন্ন শ্রেণির লোডার শ্রেণিবিন্যাস ব্যবহার করে প্রয়োগ করা হয়।
পূর্ণস্ক্রীন অভিপ্রায় জন্য অনুমতি পরিবর্তন
যে অ্যাপগুলি Android 10 বা তার বেশির দিকে লক্ষ্য করে এবং ফুলস্ক্রিন ইন্টেন্ট সহ বিজ্ঞপ্তিগুলি ব্যবহার করে তাদের অবশ্যই তাদের অ্যাপের ম্যানিফেস্ট ফাইলে USE_FULL_SCREEN_INTENT অনুমতির অনুরোধ করতে হবে। এটি একটি স্বাভাবিক অনুমতি , তাই সিস্টেম স্বয়ংক্রিয়ভাবে অনুরোধকারী অ্যাপে এটি মঞ্জুর করে।
যদি কোনো অ্যাপ যেটি Android 10 বা উচ্চতরকে লক্ষ্য করে তা প্রয়োজনীয় অনুমতির অনুরোধ ছাড়াই একটি পূর্ণস্ক্রীন অভিপ্রায় সহ একটি বিজ্ঞপ্তি তৈরি করার চেষ্টা করে, সিস্টেমটি ফুলস্ক্রিন অভিপ্রায় উপেক্ষা করে এবং নিম্নলিখিত লগ বার্তাটি আউটপুট করে:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Foldables জন্য সমর্থন
অ্যান্ড্রয়েড 10-এ এমন পরিবর্তন রয়েছে যা ফোল্ডেবল এবং বড় স্ক্রিনের ডিভাইসগুলিকে সমর্থন করে।
যখন একটি অ্যাপ অ্যান্ড্রয়েড 10 এ চলে, তখন onResume() এবং onPause() পদ্ধতি ভিন্নভাবে কাজ করে। মাল্টি-উইন্ডো বা মাল্টি-ডিসপ্লে মোডে একই সময়ে একাধিক অ্যাপ উপস্থিত হলে, দৃশ্যমান স্ট্যাকের সমস্ত ফোকাসযোগ্য শীর্ষ ক্রিয়াকলাপগুলি পুনঃসূচনা অবস্থায় থাকে, কিন্তু তাদের মধ্যে শুধুমাত্র একটি, "সর্বোচ্চ পুনঃসূচনা" কার্যকলাপে আসলে ফোকাস থাকে৷ অ্যান্ড্রয়েড 10-এর আগের সংস্করণে চলাকালীন, সিস্টেমে শুধুমাত্র একটি একক কার্যকলাপ একবারে পুনরায় শুরু করা যেতে পারে, অন্যান্য সমস্ত দৃশ্যমান ক্রিয়াকলাপ বিরাম দেওয়া হয়।
"সর্বোচ্চ পুনঃসূচনা" কার্যকলাপের সাথে "ফোকাস" কে বিভ্রান্ত করবেন না। সিস্টেমটি z-অর্ডারের উপর ভিত্তি করে ক্রিয়াকলাপের জন্য অগ্রাধিকার নির্ধারণ করে যাতে ব্যবহারকারী সর্বশেষ যে সমস্ত ক্রিয়াকলাপের সাথে ইন্টারঅ্যাক্ট করেছিল সেগুলিকে উচ্চতর অগ্রাধিকার দিতে। একটি ক্রিয়াকলাপ শীর্ষ-পুনরায় শুরু করা যেতে পারে, তবে ফোকাস নেই (উদাহরণস্বরূপ, যদি বিজ্ঞপ্তি ছায়া প্রসারিত হয়)।
Android 10 (API লেভেল 29) এবং পরবর্তীতে, আপনি onTopResumedActivityChanged() কলব্যাকে সাবস্ক্রাইব করতে পারেন যখন আপনার অ্যাক্টিভিটি শীর্ষস্থানীয় পুনঃসূচনা অবস্থান অর্জন করে বা হারায় তখন বিজ্ঞপ্তি পাওয়ার জন্য। এটি অ্যান্ড্রয়েড 10-এর আগে পুনরায় শুরু হওয়া অবস্থার সমতুল্য এবং আপনার অ্যাপ যদি এক্সক্লুসিভ বা সিঙ্গলটন রিসোর্স ব্যবহার করে থাকে যা অন্য অ্যাপের সাথে শেয়ার করার প্রয়োজন হতে পারে তাহলে এটি একটি ইঙ্গিত হিসেবে উপযোগী হতে পারে।
resizeableActivity ম্যানিফেস্ট অ্যাট্রিবিউটের আচরণও পরিবর্তিত হয়েছে। যদি কোনও অ্যাপ Android 10 (API লেভেল 29) বা তার পরে resizeableActivity=false সেট করে, তাহলে উপলব্ধ স্ক্রীনের আকার পরিবর্তন হলে বা অ্যাপটি এক স্ক্রীন থেকে অন্য স্ক্রীনে চলে গেলে এটি সামঞ্জস্যপূর্ণ মোডে রাখা হতে পারে।
অ্যাপ্লিকেশানগুলি আপনার অ্যাপ সমর্থন করে এমন স্ক্রিন অনুপাত নির্দেশ করতে Android 10-এ প্রবর্তিত android:minAspectRatio অ্যাট্রিবিউট ব্যবহার করতে পারে৷
সংস্করণ 3.5 থেকে শুরু করে, অ্যান্ড্রয়েড স্টুডিওর এমুলেটর টুলে 7.3" এবং 8" ভার্চুয়াল ডিভাইস রয়েছে যাতে বড় স্ক্রীনে আপনার কোড পরীক্ষা করা যায়।
আরও তথ্যের জন্য, ফোল্ডেবলের জন্য আপনার অ্যাপস ডিজাইন দেখুন।
, অ্যান্ড্রয়েড 10 আপডেট করা সিস্টেম আচরণ পরিবর্তনগুলি অন্তর্ভুক্ত করে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি শুধুমাত্র API 29 বা উচ্চতর টার্গেট করা অ্যাপগুলিতে প্রযোজ্য৷ যদি আপনার অ্যাপ targetSdkVersion "29" বা উচ্চতর সেট করে, তাহলে এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনার অ্যাপটি সংশোধন করা উচিত, যেখানে প্রযোজ্য।
অ্যান্ড্রয়েড 10 এ চলমান সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণের পরিবর্তনগুলির তালিকাটিও পর্যালোচনা করা নিশ্চিত করুন।
দ্রষ্টব্য: এই পৃষ্ঠায় তালিকাভুক্ত পরিবর্তনগুলি ছাড়াও, Android 10 নিম্নলিখিতগুলি সহ প্রচুর পরিমাণে গোপনীয়তা-ভিত্তিক পরিবর্তন এবং বিধিনিষেধ প্রবর্তন করে:
- স্কোপড স্টোরেজ
- ইউএসবি ডিভাইস সিরিয়াল নম্বর অ্যাক্সেস
- Wi-Fi সক্ষম, অক্ষম এবং কনফিগার করার ক্ষমতা
- সংযোগ API-এর জন্য অবস্থানের অনুমতি
এই পরিবর্তনগুলি, যা এপিআই লেভেল 29 বা তার উপরে লক্ষ্য করে এমন অ্যাপগুলিকে প্রভাবিত করে, ব্যবহারকারীর গোপনীয়তা বাড়ায়। এই পরিবর্তনগুলিকে কীভাবে সমর্থন করবেন সে সম্পর্কে আরও জানতে, গোপনীয়তা পরিবর্তন পৃষ্ঠাটি দেখুন।
নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেট
অ্যাপের স্থিতিশীলতা এবং সামঞ্জস্যতা নিশ্চিত করতে সাহায্য করার জন্য, প্ল্যাটফর্মটি Android 9 (API স্তর 28) এ আপনার অ্যাপ ব্যবহার করতে পারে এমন নন-SDK ইন্টারফেসগুলিকে সীমাবদ্ধ করা শুরু করেছে। Android 10-এ Android বিকাশকারীদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। আমাদের লক্ষ্য হল আমরা নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে তা নিশ্চিত করা।
আপনি যদি Android 10 (API লেভেল 29) টার্গেট না করেন তবে এই পরিবর্তনগুলির মধ্যে কিছু আপনাকে অবিলম্বে প্রভাবিত করতে পারে না। যাইহোক, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে ), যেকোন নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে সবসময় আপনার অ্যাপ ভাঙার উচ্চ ঝুঁকি থাকে।
আপনি যদি নিশ্চিত না হন যে আপনার অ্যাপ নন-SDK ইন্টারফেস ব্যবহার করে, তাহলে আপনি খুঁজে বের করতে আপনার অ্যাপ পরীক্ষা করতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে স্থানান্তরের পরিকল্পনা শুরু করা উচিত। তা সত্ত্বেও, আমরা বুঝি যে কিছু অ্যাপে নন-SDK ইন্টারফেস ব্যবহার করার জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। আপনি যদি আপনার অ্যাপে একটি বৈশিষ্ট্যের জন্য একটি নন-SDK ইন্টারফেস ব্যবহার করার বিকল্প খুঁজে না পান তবে আপনাকে একটি নতুন সর্বজনীন API অনুরোধ করা উচিত।
আরও জানতে, Android 10-এ নন-SDK ইন্টারফেস বিধিনিষেধের আপডেট দেখুন এবং নন-SDK ইন্টারফেসে সীমাবদ্ধতা দেখুন।
শেয়ার করা মেমরি
Ashmem /proc/<pid>/maps-এ ডালভিক মানচিত্রের বিন্যাস পরিবর্তন করেছে, যা ম্যাপ ফাইলকে সরাসরি পার্স করে এমন অ্যাপগুলিকে প্রভাবিত করে। অ্যাপ্লিকেশান বিকাশকারীদের /proc/<pid>/maps ফরম্যাট পরীক্ষা করা উচিত যেগুলি Android 10 বা উচ্চতর চালায় এবং অ্যাপটি ডালভিক মানচিত্র ফর্ম্যাটের উপর নির্ভর করে সেই অনুযায়ী পার্স করুন৷
Android 10 টার্গেট করা অ্যাপগুলি সরাসরি ashmem (/dev/ashmem) ব্যবহার করতে পারে না এবং পরিবর্তে NDK-এর ASharedMemory ক্লাসের মাধ্যমে শেয়ার করা মেমরি অ্যাক্সেস করতে হবে। উপরন্তু, অ্যাপগুলি বিদ্যমান অ্যাশমেম ফাইল বর্ণনাকারীদের সরাসরি IOCTL তৈরি করতে পারে না এবং এর পরিবর্তে শেয়ার করা মেমরি অঞ্চল তৈরির জন্য NDK-এর ASharedMemory ক্লাস বা Android Java API ব্যবহার করতে হবে। শেয়ার্ড মেমরির সাথে কাজ করার সময় এই পরিবর্তন নিরাপত্তা এবং দৃঢ়তা বাড়ায়, সামগ্রিকভাবে Android এর কর্মক্ষমতা এবং নিরাপত্তা উন্নত করে।
অ্যাপ হোম ডিরেক্টরির জন্য এক্সিকিউট অনুমতি সরানো হয়েছে
লিখনযোগ্য অ্যাপ হোম ডিরেক্টরি থেকে ফাইলগুলি সম্পাদন করা একটি W^X লঙ্ঘন । অ্যাপগুলির শুধুমাত্র বাইনারি কোড লোড করা উচিত যা একটি অ্যাপের APK ফাইলের মধ্যে এমবেড করা আছে।
Android 10 টার্গেট করে এমন অবিশ্বস্ত অ্যাপগুলি অ্যাপের হোম ডিরেক্টরির মধ্যে থাকা ফাইলগুলিতে সরাসরি execve() চালু করতে পারে না।
উপরন্তু, যে অ্যাপগুলি Android 10 কে লক্ষ্য করে সেগুলি dlopen() দিয়ে খোলা ফাইলগুলি থেকে এক্সিকিউটেবল কোড ইন-মেমরি পরিবর্তন করতে পারে না এবং সেই পরিবর্তনগুলি ডিস্কের মাধ্যমে লেখার আশা করে, কারণ লাইব্রেরিটি একটি লিখনযোগ্য ফাইল বর্ণনাকারীর মাধ্যমে PROT_EXEC ম্যাপ করা যায় না। এতে টেক্সট রিলোকেশন সহ যেকোনও শেয়ার করা অবজেক্ট ( .so ) ফাইল অন্তর্ভুক্ত থাকে।
অ্যান্ড্রয়েড রানটাইম শুধুমাত্র সিস্টেম-জেনারেটেড OAT ফাইল গ্রহণ করে
অ্যান্ড্রয়েড রানটাইম (ART) আর আবেদন প্রক্রিয়া থেকে dex2oat ব্যবহার করে না। এই পরিবর্তনের মানে হল যে ART শুধুমাত্র OAT ফাইলগুলি গ্রহণ করবে যা সিস্টেম তৈরি করেছে।
ART এ AOT সঠিকতা প্রয়োগ করা
অতীতে, অ্যান্ড্রয়েড রানটাইম (এআরটি) দ্বারা সম্পাদিত অগ্র-অফ-টাইম (AOT) সংকলনটি রানটাইম ক্র্যাশের কারণ হতে পারে যদি কম্পাইল টাইম এবং রানটাইমে ক্লাসপথের পরিবেশ একই না হয়। অ্যান্ড্রয়েড 10 এবং উচ্চতরের জন্য সর্বদা এই পরিবেশের প্রসঙ্গগুলি একই হওয়া প্রয়োজন, যার ফলে আচরণে নিম্নলিখিত পরিবর্তনগুলি ঘটে:
- কাস্টম ক্লাস লোডার—অর্থাৎ, অ্যাপ দ্বারা লেখা ক্লাস লোডার,
dalvik.systemপ্যাকেজের ক্লাস লোডারের বিপরীতে—এওটি-সংকলিত হয় না। কারণ রানটাইমে কাস্টমাইজড ক্লাস লুকআপ বাস্তবায়ন সম্পর্কে ART জানতে পারে না। - সেকেন্ডারি ডেক্স ফাইল—অর্থাৎ, প্রাথমিক APK-এ নেই এমন অ্যাপের মাধ্যমে ম্যানুয়ালি লোড করা ডেক্স ফাইলগুলি-ব্যাকগ্রাউন্ডে AOT-সংকলিত। এর কারণ হল প্রথম-ব্যবহারের সংকলন খুব ব্যয়বহুল হতে পারে, যা কার্যকর করার আগে অবাঞ্ছিত বিলম্বের দিকে পরিচালিত করে। মনে রাখবেন যে অ্যাপগুলির জন্য, স্প্লিটগুলি গ্রহণ করা এবং সেকেন্ডারি ডেক্স ফাইলগুলি থেকে দূরে সরে যাওয়ার পরামর্শ দেওয়া হয়।
- অ্যান্ড্রয়েডের শেয়ার্ড লাইব্রেরিগুলি (একটি অ্যান্ড্রয়েড ম্যানিফেস্টে <লাইব্রেরি> এবং <ব্যবহার-লাইব্রেরি> এন্ট্রি) প্লাটফর্মের পূর্ববর্তী সংস্করণগুলিতে ব্যবহৃত একটি থেকে ভিন্ন শ্রেণির লোডার শ্রেণিবিন্যাস ব্যবহার করে প্রয়োগ করা হয়।
পূর্ণস্ক্রীন অভিপ্রায় জন্য অনুমতি পরিবর্তন
যে অ্যাপগুলি Android 10 বা তার বেশির দিকে লক্ষ্য করে এবং ফুলস্ক্রিন ইন্টেন্ট সহ বিজ্ঞপ্তিগুলি ব্যবহার করে তাদের অবশ্যই তাদের অ্যাপের ম্যানিফেস্ট ফাইলে USE_FULL_SCREEN_INTENT অনুমতির অনুরোধ করতে হবে। এটি একটি স্বাভাবিক অনুমতি , তাই সিস্টেম স্বয়ংক্রিয়ভাবে অনুরোধকারী অ্যাপে এটি মঞ্জুর করে।
যদি কোনো অ্যাপ যেটি Android 10 বা উচ্চতরকে লক্ষ্য করে তা প্রয়োজনীয় অনুমতির অনুরোধ ছাড়াই একটি পূর্ণস্ক্রীন অভিপ্রায় সহ একটি বিজ্ঞপ্তি তৈরি করার চেষ্টা করে, সিস্টেমটি ফুলস্ক্রিন অভিপ্রায় উপেক্ষা করে এবং নিম্নলিখিত লগ বার্তাটি আউটপুট করে:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Foldables জন্য সমর্থন
অ্যান্ড্রয়েড 10-এ এমন পরিবর্তন রয়েছে যা ফোল্ডেবল এবং বড় স্ক্রিনের ডিভাইসগুলিকে সমর্থন করে।
যখন একটি অ্যাপ অ্যান্ড্রয়েড 10 এ চলে, তখন onResume() এবং onPause() পদ্ধতি ভিন্নভাবে কাজ করে। মাল্টি-উইন্ডো বা মাল্টি-ডিসপ্লে মোডে একই সময়ে একাধিক অ্যাপ উপস্থিত হলে, দৃশ্যমান স্ট্যাকের সমস্ত ফোকাসযোগ্য শীর্ষ ক্রিয়াকলাপগুলি পুনঃসূচনা অবস্থায় থাকে, কিন্তু তাদের মধ্যে শুধুমাত্র একটি, "সর্বোচ্চ পুনঃসূচনা" কার্যকলাপে আসলে ফোকাস থাকে৷ অ্যান্ড্রয়েড 10-এর আগের সংস্করণে চলাকালীন, সিস্টেমে শুধুমাত্র একটি একক কার্যকলাপ একবারে পুনরায় শুরু করা যেতে পারে, অন্যান্য সমস্ত দৃশ্যমান ক্রিয়াকলাপ বিরাম দেওয়া হয়।
"সর্বোচ্চ পুনঃসূচনা" কার্যকলাপের সাথে "ফোকাস" কে বিভ্রান্ত করবেন না। সিস্টেমটি z-অর্ডারের উপর ভিত্তি করে ক্রিয়াকলাপের জন্য অগ্রাধিকার নির্ধারণ করে যাতে ব্যবহারকারী সর্বশেষ যে সমস্ত ক্রিয়াকলাপের সাথে ইন্টারঅ্যাক্ট করেছিল সেগুলিকে উচ্চতর অগ্রাধিকার দিতে। একটি ক্রিয়াকলাপ শীর্ষ-পুনরায় শুরু করা যেতে পারে, তবে ফোকাস নেই (উদাহরণস্বরূপ, যদি বিজ্ঞপ্তি ছায়া প্রসারিত হয়)।
Android 10 (API লেভেল 29) এবং পরবর্তীতে, আপনি onTopResumedActivityChanged() কলব্যাকে সাবস্ক্রাইব করতে পারেন যখন আপনার অ্যাক্টিভিটি শীর্ষস্থানীয় পুনঃসূচনা অবস্থান অর্জন করে বা হারায় তখন বিজ্ঞপ্তি পাওয়ার জন্য। এটি অ্যান্ড্রয়েড 10-এর আগে পুনরায় শুরু হওয়া অবস্থার সমতুল্য এবং আপনার অ্যাপ যদি এক্সক্লুসিভ বা সিঙ্গলটন রিসোর্স ব্যবহার করে থাকে যা অন্য অ্যাপের সাথে শেয়ার করার প্রয়োজন হতে পারে তাহলে এটি একটি ইঙ্গিত হিসেবে উপযোগী হতে পারে।
resizeableActivity ম্যানিফেস্ট অ্যাট্রিবিউটের আচরণও পরিবর্তিত হয়েছে। যদি কোনও অ্যাপ Android 10 (API লেভেল 29) বা তার পরে resizeableActivity=false সেট করে, তাহলে উপলব্ধ স্ক্রীনের আকার পরিবর্তন হলে বা অ্যাপটি এক স্ক্রীন থেকে অন্য স্ক্রীনে চলে গেলে এটি সামঞ্জস্যপূর্ণ মোডে রাখা হতে পারে।
অ্যাপ্লিকেশানগুলি আপনার অ্যাপ সমর্থন করে এমন স্ক্রিন অনুপাত নির্দেশ করতে Android 10-এ প্রবর্তিত android:minAspectRatio অ্যাট্রিবিউট ব্যবহার করতে পারে৷
সংস্করণ 3.5 থেকে শুরু করে, অ্যান্ড্রয়েড স্টুডিওর এমুলেটর টুলে 7.3" এবং 8" ভার্চুয়াল ডিভাইস রয়েছে যাতে বড় স্ক্রীনে আপনার কোড পরীক্ষা করা যায়।
আরও তথ্যের জন্য, ফোল্ডেবলের জন্য আপনার অ্যাপস ডিজাইন দেখুন।