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