Android ১২ প্ল্যাটফর্মে আচরণগত পরিবর্তন অন্তর্ভুক্ত আছে যা আপনার অ্যাপকে
প্রভাবিত করতে পারে। নিম্নলিখিত আচরণগত পরিবর্তন সব অ্যাপের ক্ষেত্রে প্রযোজ্য হয় যখন সেগুলি
Android ১২-এ চলে, targetSdkVersion নির্বিশেষে। আপনার অ্যাপ
পরীক্ষা করে দেখা উচিত এবং যেখানে প্রযোজ্য সেখানে এগুলি সঠিকভাবে কাজ করার জন্য
প্রয়োজন অনুযায়ী পরিবর্তন করা উচিত।
এছাড়াও, Android 12-কে টার্গেট করা অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকা পর্যালোচনা করতে ভুলবেন না।
ব্যবহারকারীর অভিজ্ঞতা
স্ট্রেচ ওভারস্ক্রল এফেক্ট
Android 12 ও তার পরবর্তী ভার্সন ইনস্টল করা আছে এমন ডিভাইসে, ওভারস্ক্রল ইভেন্ট-এর জন্য ভিজ্যুয়াল আচরণ পরিবর্তিত হয়।
Android 11 ও তার আগের ভার্সনে, ওভারস্ক্রল ইভেন্টের কারণে ভিজ্যুয়াল এলিমেন্ট উজ্জ্বল হয়ে ওঠে; Android 12 ও তার পরের ভার্সনে, ড্র্যাগ ইভেন্টের ক্ষেত্রে ভিজ্যুয়াল এলিমেন্ট বড় হয়ে যায় এবং বাউন্স করে আগের অবস্থায় ফিরে আসে এবং ফ্লিং ইভেন্টের ক্ষেত্রে ফ্লিং করে এবং বাউন্স করে আগের অবস্থায় ফিরে আসে।
আরও তথ্যের জন্য, স্ক্রল জেসচার অ্যানিমেট করা সংক্রান্ত নির্দেশিকা দেখুন।
অ্যাপ স্প্ল্যাশ স্ক্রিন
আপনি যদি আগে Android 11 বা তার আগের ভার্সনে কাস্টম স্প্ল্যাশ স্ক্রিন প্রয়োগ করে থাকেন, তাহলে Android 12 থেকে শুরু করে এটি সঠিকভাবে ডিসপ্লে হচ্ছে কিনা তা নিশ্চিত করতে, আপনাকে SplashScreen API-তে আপনার অ্যাপ মাইগ্রেট করতে হবে। আপনার অ্যাপ মাইগ্রেট না করলে,
অ্যাপ লঞ্চ করার অভিজ্ঞতা খারাপ বা অপ্রত্যাশিত হতে পারে।
নির্দেশাবলীর জন্য, আপনার আগে থেকে থাকা স্প্ল্যাশ স্ক্রিন ইমপ্লিমেন্টেশন Android 12-এ মাইগ্রেট করুন দেখুন।
এছাড়াও, Android 12 থেকে শুরু করে, সিস্টেম সবসময় সব অ্যাপের জন্য কোল্ড এবং
ওয়ার্ম স্টার্টে নতুন Android
সিস্টেম ডিফল্ট স্প্ল্যাশ স্ক্রিন প্রয়োগ করে।
ডিফল্ট হিসেবে, এই সিস্টেম ডিফল্ট স্প্ল্যাশ স্ক্রিন আপনার অ্যাপের লঞ্চার আইকন এলিমেন্ট এবং আপনার থিমের
windowBackground (যদি এটি একটি রঙ হয়)
ব্যবহার করে তৈরি করা হয়।
আরও জানতে, স্প্ল্যাশ স্ক্রিন ডেভেলপার নির্দেশিকা দেখুন।
ওয়েব ইনটেন্ট রেজোলিউশন
Android 12 (API লেভেল 31) থেকে শুরু করে, কোনও জেনেরিক ওয়েব ইনটেন্ট আপনার অ্যাপে কোনও অ্যাক্টিভিটি তখনই সমাধান করে, যদি আপনার অ্যাপ সেই ওয়েব ইনটেন্টে থাকা নির্দিষ্ট ডোমেনের জন্য অনুমোদিত হয়। আপনার অ্যাপ ডোমেনের জন্য অনুমোদিত না হলে, ওয়েব ইনটেন্ট ব্যবহারকারীর ডিফল্ট ব্রাউজার অ্যাপে সমাধান করে।
অ্যাপ নিম্নলিখিত যেকোনও একটি কাজ করে এই অনুমোদন পেতে পারে:
Android অ্যাপ লিঙ্ক ব্যবহার করে ডোমেন যাচাই করুন।
Android 12 বা তার পরবর্তী ভার্সনকে টার্গেট করে এমন অ্যাপের ক্ষেত্রে, সিস্টেম আপনার অ্যাপের Android অ্যাপ লিঙ্ক যেভাবে অটোমেটিক যাচাই করে তা পরিবর্তন করে। আপনার অ্যাপের ইনটেন্ট ফিল্টারে, চেক করে দেখুন যে আপনি
BROWSABLEবিভাগ অন্তর্ভুক্ত করেছেন এবংhttpsস্কিমকে সমর্থন করেন।Android 12 বা তার পরবর্তী যেকোনও ভার্সনে, আপনি অ্যাপের Android অ্যাপ লিঙ্ক ম্যানুয়ালি যাচাই করতে পারবেন, যাতে এই আপডেট করা লজিক আপনার অ্যাপকে কীভাবে প্রভাবিত করে তা পরীক্ষা করতে পারেন।
ব্যবহারকারীকে সিস্টেম সেটিংসে আপনার অ্যাপকে domain-এর সাথে অ্যাসোসিয়েট করতে বলুন।
আপনার অ্যাপ ওয়েব ইনটেন্ট ইনভোক করলে, ব্যবহারকারীকে অ্যাকশন কনফার্ম করতে বলে এমন প্রম্পট বা ডায়ালগ যোগ করার কথা বিবেচনা করুন।
জেসচার নেভিগেশনের জন্য ইমারসিভ মোডের উন্নতি
Android 12-এ বর্তমান আচরণকে একত্রিত করা হয়েছে যাতে ব্যবহারকারীরা সহজেই ইমারসিভ মোডে থাকাকালীন জেসচার নেভিগেশন কমান্ড পারফর্ম করতে পারেন। এছাড়াও, Android 12-এ স্টিকি ইমারসিভ মোডের জন্য ব্যাকওয়ার্ড কম্প্যাটিবিলিটি আচরণ প্রদান করা হয়।
Display#getRealSize এবং getRealMetrics: অবচিতি এবং সীমাবদ্ধতা
Android ডিভাইস বিভিন্ন ফর্ম ফ্যাক্টরে উপলভ্য, যেমন বড় স্ক্রিন, ট্যাবলেট ও ফোল্ডেবল। প্রতিটি ডিভাইসে কন্টেন্ট সঠিকভাবে রেন্ডার করার জন্য, আপনার অ্যাপকে স্ক্রিন বা ডিসপ্লের সাইজ নির্ধারণ করতে হবে। সময়ের সাথে সাথে,
Android এই তথ্য ফিরিয়ে আনার জন্য বিভিন্ন API প্রদান করেছে। Android
11-এ, আমরা WindowMetrics
API নিয়ে এসেছি এবং এইসব পদ্ধতি বাতিল করেছি:
Android 12-এ আমরা WindowMetrics ব্যবহার করার সাজেশন দেওয়া চালিয়ে যাচ্ছি এবং
এইসব পদ্ধতি বন্ধ করে দিচ্ছি:
অ্যাপ্লিকেশনের বাউন্ডারি পুনরুদ্ধার করতে ডিসপ্লে API ব্যবহার করে এমন অ্যাপ্লিকেশনের আচরণ প্রশমিত করতে, Android 12 সম্পূর্ণরূপে রিসাইজ করা যায় না এমন অ্যাপের জন্য API দ্বারা রিটার্ন করা মানগুলিকে সীমাবদ্ধ করে। MediaProjection-এর সাথে এই তথ্য ব্যবহার করছে এমন অ্যাপের উপর
এর প্রভাব পড়তে পারে।
অ্যাপের উইন্ডোর বাউন্ড কোয়েরি করতে WindowMetrics API ব্যবহার করা উচিত এবং
বর্তমান ডেনসিটি কোয়েরি করতে Configuration.densityDpi
ব্যবহার করা উচিত।
Android-এর পুরনো ভার্সনের সাথে আরও বেশি মানানসই করার জন্য, আপনি
Jetpack WindowManager লাইব্রেরি ব্যবহার করতে পারেন, যার মধ্যে
একটি WindowMetrics ক্লাস অন্তর্ভুক্ত থাকে
যা Android 4.0 (API লেভেল 14) এবং তার পরবর্তী ভার্সনে কাজ করে।
WindowMetrics কীভাবে ব্যবহার করতে হয় তার উদাহরণ
প্রথমে, আপনার অ্যাপের অ্যাক্টিভিটি সম্পূর্ণ ছোট বড় করা যায় কিনা তা নিশ্চিত করুন।
UI-সম্পর্কিত যেকোনও কাজের জন্য অ্যাক্টিভিটি কনটেক্সট থেকে অ্যাক্টিভিটিকে WindowMetrics-এর উপর নির্ভর করতে হবে, বিশেষ করে
WindowManager.getCurrentWindowMetrics()
বা Jetpack-এর
WindowMetricsCalculator.computeCurrentWindowMetrics()।
আপনার অ্যাপ MediaProjection তৈরি করলে, বাউন্ডের সাইজ সঠিক হতে হবে
কারণ প্রোজেকশন সেই ডিসপ্লে পার্টিশন ক্যাপচার করে যেখানে প্রোজেক্টর অ্যাপ
চালানো হচ্ছে।
অ্যাপের সাইজ সম্পূর্ণভাবে পরিবর্তন করা গেলে, অ্যাক্টিভিটি কন্টেক্সট সঠিক বাউন্ড রিটার্ন করে যেমন:
Kotlin
val projectionMetrics: WindowMetrics = activityContext .getSystemService(WindowManager::class.java).maximumWindowMetrics
জাভা
WindowMetrics projectionMetrics = activityContext .getSystemService(WindowManager.class).getMaximumWindowMetrics();
অ্যাপটি সম্পূর্ণভাবে ছোট বড় করা না গেলে, এটি অবশ্যই একটি WindowContext
ইনস্ট্যান্স থেকে কোয়েরি করতে হবে এবং
WindowManager.getMaximumWindowMetrics()
বা Jetpack পদ্ধতি
WindowMetricsCalculator.computeMaximumWindowMetrics() ব্যবহার করে অ্যাক্টিভিটি বাউন্ডের WindowMetrics ফিরিয়ে আনতে হবে।
Kotlin
val windowContext = context.createWindowContext(mContext.display!!, WindowManager.LayoutParams.TYPE_APPLICATION, null) val projectionMetrics = windowContext.getSystemService(WindowManager::class.java) .maximumWindowMetrics
জাভা
Context windowContext = context.createWindowContext(mContext.getDisplay(), WindowManager.LayoutParams.TYPE_APPLICATION, null); WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class) .getMaximumWindowMetrics();
মাল্টি-উইন্ডো মোডে সব অ্যাপ
Android ১২-এ মাল্টি-উইন্ডো মোড স্ট্যান্ডার্ড আচরণ হিসেবে সেট করা থাকে।
বড় স্ক্রিনে (sw >= 600dp), প্ল্যাটফর্মটি অ্যাপ কনফিগারেশন নির্বিশেষে মাল্টি-উইন্ডো মোডে সব অ্যাপকে
সমর্থন করে। যদি
resizeableActivity="false",
ডিসপ্লে ডাইমেনশন মানানসই করার জন্য প্রয়োজন হলে অ্যাপটি কম্প্যাটিবিলিটি মোডে রাখা হয়।
ছোট স্ক্রিনে (sw < 600dp), অ্যাক্টিভিটি মাল্টি-উইন্ডো মোডে চলতে পারে কিনা তা নির্ধারণ করতে সিস্টেম অ্যাক্টিভিটির
minWidth
এবং
minHeight
চেক করে। resizeableActivity="false"
হলে,
ন্যূনতম প্রস্থ ও উচ্চতা যাই হোক না কেন, অ্যাপটি মাল্টি‑উইন্ডো মোডে চলতে পারে না।
আরও তথ্যের জন্য, মাল্টি-উইন্ডো সাপোর্ট দেখুন।
বড় স্ক্রিনে ক্যামেরা প্রিভিউ
ক্যামেরা অ্যাপ সাধারণত ডিভাইসের ওরিয়েন্টেশন এবং ক্যামেরা প্রিভিউয়ের অ্যাস্পেক্ট রেশিওর মধ্যে একটি নির্দিষ্ট সম্পর্ক ধরে নেয়। কিন্তু ফোল্ডেবল ডিভাইসের মতো বড় স্ক্রিন ফর্ম ফ্যাক্টর এবং মাল্টি-উইন্ডো ও মাল্টি-ডিসপ্লের মতো ডিসপ্লে মোড এই ধারণাকে চ্যালেঞ্জ করে।
Android 12-এ, যেসব ক্যামেরা অ্যাপ নির্দিষ্ট স্ক্রিন ওরিয়েন্টেশনের অনুরোধ করে এবং যেগুলির সাইজ পরিবর্তন করা যায় না (resizeableActivity="false"), সেগুলি অটোমেটিক ইনসেট পোর্ট্রেট মোডে চলে যায়। এর ফলে ক্যামেরা প্রিভিউয়ের সঠিক ওরিয়েন্টেশন এবং অ্যাস্পেক্ট রেশিও নিশ্চিত করা যায়। যেসব ফোল্ডেবল ও অন্যান্য ডিভাইসে ক্যামেরা
হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) আছে,
সেগুলিতে ক্যামেরা সেন্সর ওরিয়েন্টেশনের ক্ষতিপূরণ করতে ক্যামেরা আউটপুটে অতিরিক্ত রোটেশন প্রয়োগ করা হয়
এবং অ্যাপের ক্যামেরা প্রিভিউয়ের অ্যাস্পেক্ট রেশিওর সাথে ম্যাচ করার জন্য ক্যামেরা আউটপুট ক্রপ করা হয়। ক্রপ করা এবং অতিরিক্ত রোটেশন নিশ্চিত করে যে ডিভাইসের ওরিয়েন্টেশন এবং ডিভাইস ভাঁজ করা বা খোলা অবস্থায় থাকা নির্বিশেষে ক্যামেরা প্রিভিউ সঠিকভাবে উপস্থাপন করা হয়েছে।
ফোরগ্রাউন্ড সার্ভিস বিজ্ঞপ্তির জন্য UX বিলম্ব
অল্প সময়ের জন্য চলা ফোরগ্রাউন্ড পরিষেবা-এর জন্য স্ট্রিমলাইন করা অভিজ্ঞতা প্রদান করতে, Android 12 বা তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইস, ফোরগ্রাউন্ড পরিষেবার বিজ্ঞপ্তি ১০ সেকেন্ড দেরিতে দেখাতে পারে, কিছু ব্যতিক্রম সহ। এই পরিবর্তনের ফলে, অল্প সময়ের জন্য চলা টাস্কের বিজ্ঞপ্তি দেখানোর আগেই তা সম্পূর্ণ করার সুযোগ পাওয়া যায়।
পারফর্ম্যান্স
সীমাবদ্ধ অ্যাপ স্ট্যান্ডবাই বাকেট
Android 11 (API লেভেল ৩০) ভার্সনে অ্যাপ স্ট্যান্ডবাই বাকেট হিসেবে সীমাবদ্ধ বাকেট চালু করা হয়েছে। Android 12 থেকে শুরু করে, এই বাকেট ডিফল্ট হিসেবে অ্যাক্টিভ থাকে। সব বাকেটের মধ্যে সীমাবদ্ধ বাকেটের অগ্রাধিকার সবচেয়ে কম (এবং সবচেয়ে বেশি বিধিনিষেধ) থাকে। বেশি থেকে কম অগ্রাধিকারের ক্রমে বাকেটগুলি হল:
- অ্যাক্টিভ: অ্যাপটি বর্তমানে ব্যবহার করা হচ্ছে বা খুব সম্প্রতি ব্যবহার করা হয়েছে।
- ওয়ার্কিং সেট: অ্যাপ নিয়মিত ব্যবহার করা হয়।
- ঘন ঘন: অ্যাপটি প্রায়ই ব্যবহার করা হয়, তবে প্রতিদিন নয়।
- বিরল: অ্যাপটি ঘন ঘন ব্যবহার করা হয় না।
- সীমাবদ্ধ: অ্যাপটি প্রচুর পরিমাণে সিস্টেম রিসোর্স ব্যবহার করে বা অবাঞ্ছিত আচরণ প্রদর্শন করতে পারে।
আপনার অ্যাপকে সীমাবদ্ধ বাকেটে রাখা হবে কিনা তা সিদ্ধান্ত নিতে, সিস্টেম ব্যবহারের প্যাটার্ন ছাড়াও আপনার অ্যাপের আচরণ বিবেচনা করে।
আপনার অ্যাপ সিস্টেম রিসোর্স আরও দায়িত্ব সহকারে ব্যবহার করলে, সেটি সীমাবদ্ধ বালতিতে রাখার সম্ভাবনা কম। এছাড়াও, ব্যবহারকারী সরাসরি আপনার অ্যাপের সাথে ইন্টার্যাক্ট করলে, সিস্টেম আপনার অ্যাপকে কম সীমাবদ্ধতাযুক্ত বাকেটে রাখে।
আপনার অ্যাপটি বিধিনিষেধযুক্ত বাকেটে আছে কিনা তা চেক করুন
সিস্টেম আপনার অ্যাপকে সীমাবদ্ধ বাকেটে রেখেছে কিনা তা চেক করতে, getAppStandbyBucket() কল করুন।
এই পদ্ধতির রিটার্ন ভ্যালু STANDBY_BUCKET_RESTRICTED হলে, আপনার অ্যাপ
রেস্ট্রিক্টেড বাকেটে আছে।
বিধিনিষেধযুক্ত বাকেট আচরণ পরীক্ষা করুন
সিস্টেম আপনার অ্যাপকে বিধিনিষেধযুক্ত বাকেটে রাখলে, আপনার অ্যাপ কেমন আচরণ করে তা পরীক্ষা করতে, আপনি ম্যানুয়ালি আপনার অ্যাপকে সেই বাকেটে সরাতে পারেন। এটি করতে, টার্মিনাল উইন্ডোতে নিম্নলিখিত কমান্ড রান করুন:
adb shell am set-standby-bucket PACKAGE_NAME restricted
ফোরগ্রাউন্ড লোকেশন ও ব্যাটারি সেভার
Android 12 থেকে শুরু করে, ব্যাটারি সেভার চালু থাকা অবস্থায়, এমনকি স্ক্রিন বন্ধ থাকলেও, ফোরগ্রাউন্ড লোকেশন (ফোরগ্রাউন্ড পরিষেবা থেকে সহ) ডেলিভার করা চালিয়ে যাওয়া যেতে পারে।
আগে, স্ক্রিন বন্ধ থাকলে ব্যাটারি সেভার মোড লোকেশন আপডেট বন্ধ করে দিত। এই পরিবর্তনের ফলে ব্যবহারকারীদের ব্যাটারির আয়ু আরও ভালো হয় এবং এর অর্থ হল, লোকেশন ডেলিভারি নিশ্চিত করার জন্য ডেভেলপাররা ব্যবহারকারীদের ব্যাটারি সেভার বন্ধ করতে বলার থেকে বিরত থাকতে পারেন।
যেসব অ্যাপ ফোরগ্রাউন্ড পরিষেবার মাধ্যমে লোকেশন অ্যাক্সেস করার অনুরোধ করে, তাদের নিম্নলিখিত ধাপগুলি অনুসরণ করতে হবে:
- ব্যাটারি সেভার চালু থাকলে ডিভাইসের লোকেশন ফিচার কীভাবে কাজ করে তা চেক করতে
getLocationPowerSaverMode()কল করুন। - এটি
LOCATION_MODE_FOREGROUND_ONLYরিটার্ন করলে, আপনার অ্যাপ ফোরগ্রাউন্ডে থাকাকালীন বা ব্যাটারি সেভার চালু ও স্ক্রিন বন্ধ থাকা অবস্থায় ফোরগ্রাউন্ড সার্ভিস চালানোর সময় লোকেশন আপডেট পেতে থাকবে।
নিরাপত্তা ও গোপনীয়তা
আনুমানিক লোকেশন
Android ১২ বা তার পরবর্তী ভার্সন চলে এমন ডিভাইসে, ব্যবহারকারীরা অনুরোধ করতে পারেন যে আপনার অ্যাপের কাছে শুধুমাত্র আনুমানিক লোকেশন তথ্য অ্যাক্সেস করার অনুমতি থাকবে।
আপনার অ্যাপ
ACCESS_FINE_LOCATION
রানটাইম অনুমতির অনুরোধ করলে, ব্যবহারকারী আপনার অ্যাপকে আনুমানিক লোকেশন অ্যাক্সেস করার অনুমতি দিলে,
ACCESS_COARSE_LOCATION
অনুমতির অনুরোধও করা উচিত। আপনাকে একটি রানটাইম
অনুরোধে দুটি অনুমতিই অন্তর্ভুক্ত করতে হবে।
সিস্টেম সংক্রান্ত অনুমতির ডায়ালগে ব্যবহারকারীর জন্য নিম্নলিখিত বিকল্পগুলি অন্তর্ভুক্ত থাকে, যেমনটি ছবি ১-এ দেখানো হয়েছে:
- সুনির্দিষ্ট: সুনির্দিষ্ট লোকেশন সংক্রান্ত তথ্য অ্যাক্সেস করার অনুমতি দেয়।
- আনুমানিক: শুধুমাত্র আনুমানিক লোকেশন সংক্রান্ত তথ্যে অ্যাক্সেস প্রদান করে।
মাইক্রোফোন ও ক্যামেরা টগল
Android ১২ বা তার পরবর্তী যেকোনও ভার্সন কাজ করে এমন ডিভাইসে ব্যবহারকারীরা একটি টগল বিকল্প প্রেস করেই ডিভাইসের সব অ্যাপের জন্য ক্যামেরা ও মাইক্রোফোন অ্যাক্সেস চালু ও বন্ধ করতে পারবেন। ব্যবহারকারীরা দ্রুত সেটিংস থেকে টগল করা যায় এমন বিকল্প অ্যাক্সেস করতে পারবেন, যেমনটি ছবি ১-এ দেখানো হয়েছে অথবা সিস্টেম সেটিংসের গোপনীয়তা স্ক্রিন থেকে।
এইসব টগল সম্পর্কে আরও জানুন এবং
CAMERA ও
RECORD_AUDIO
অনুমতির ক্ষেত্রে আপনার অ্যাপ পেশাদার পদ্ধতি অনুসরণ করছে কিনা তা কীভাবে চেক করবেন তা জানুন।
মাইক্রোফোন ও ক্যামেরা ইন্ডিকেটর
Android ১২ বা তার পরবর্তী যেকোনও ভার্সনে চলে এমন ডিভাইসে, কোনও অ্যাপ মাইক্রোফোন বা ক্যামেরা অ্যাক্সেস করলে, স্ট্যাটাস বারে একটি আইকন দেখা যায়।
এইসব
ইন্ডিকেটর সম্পর্কে আরও জানুন এবং
CAMERA ও
RECORD_AUDIO
অনুমতির ব্যাপারে আপনার অ্যাপ পেশাদার পদ্ধতি অনুসরণ করছে কিনা তা কীভাবে
চেক করবেন তা জানুন।
প্যাকেজ দৃশ্যমানতার অনুমতি
Android 12 বা তার পরবর্তী যেকোনও ভার্সনে চলে এমন ডিভাইসে, Android 11 (API লেভেল 30) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করে এমন অ্যাপ এবং নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটিকে কল করে এমন অ্যাপ, অন্যান্য অ্যাপে অ্যাপের প্যাকেজ দৃশ্যমানতা-এর উপর ভিত্তি করে ফলাফলের একটি ফিল্টার করা সেট পায়:
BouncyCastle ইমপ্লিমেন্টেশন সরানো হয়েছে
Android 12-এ ক্রিপ্টোগ্রাফিক অ্যালগরিদমের অনেক BouncyCastle ইমপ্লিমেন্টেশন সরিয়ে দেওয়া হয়েছে, যেগুলি আগে বাতিল করা হয়েছিল, এর মধ্যে সব AES অ্যালগরিদম অন্তর্ভুক্ত। পরিবর্তে সিস্টেম এই অ্যালগরিদমগুলির Conscrypt ইমপ্লিমেন্টেশন ব্যবহার করে।
নিচে উল্লেখ করা যেকোনও একটি সত্যি হলে, এই পরিবর্তন আপনার অ্যাপকে প্রভাবিত করবে:
- আপনার অ্যাপ ৫১২-বিট কী-এর সাইজ ব্যবহার করে। Conscrypt-এ এই সাইজের কী কাজ করে না। প্রয়োজন হলে, বিভিন্ন কি-এর সাইজ ব্যবহার করার জন্য আপনার অ্যাপের ক্রিপটোগ্রাফি লজিক আপডেট করুন।
আপনার অ্যাপ
KeyGenerator-এর সাথে ভুল সাইজের কী ব্যবহার করে। BouncyCastle-এর তুলনায় Conscrypt-এরKeyGenerator-এর প্রয়োগ কী প্যারামিটারে অতিরিক্ত যাচাইকরণ সম্পন্ন করে। যেমন, Conscrypt আপনার অ্যাপকে ৬৪-বিট AES কী তৈরি করতে দেয় না কারণ AES শুধুমাত্র ১২৮-, ১৯২- এবং ২৫৬-বিট কী সাপোর্ট করে।BouncyCastle ভুল সাইজের কী তৈরি করার অনুমতি দেয়, কিন্তু পরে
Cipher-এর সাথে এইসব কী ব্যবহার করা হলে তা কাজ করে না। Conscrypt আগে ব্যর্থ হয়েছে।আপনি ১২ বাইট ছাড়া অন্য সাইজ ব্যবহার করে Galois/Counter Mode (GCM) সাইফার ইনিশিয়ালাইজ করেন।
GcmParameterSpec-এর Conscrypt প্রয়োগের জন্য ১২ বাইটের ইনিশিয়ালাইজেশন প্রয়োজন, যা NIST সাজেস্ট করে।
ক্লিপবোর্ড অ্যাক্সেস সংক্রান্ত বিজ্ঞপ্তি
Android ১২ ও তার পরবর্তী ভার্সনে, কোনও অ্যাপ প্রথমবার
getPrimaryClip()
অন্য অ্যাপ থেকে ক্লিপ ডেটা অ্যাক্সেস করার জন্য কল করলে, একটি টোস্ট মেসেজ ব্যবহারকারীকে এই ক্লিপবোর্ড অ্যাক্সেস সম্পর্কে
বিজ্ঞপ্তি দেয়।
টোস্ট মেসেজের মধ্যে থাকা টেক্সটে নিম্নলিখিত ফর্ম্যাট থাকে:
APP pasted from your clipboard.
ক্লিপের বিবরণে টেক্সট সংক্রান্ত তথ্য
Android 12 ও এর পরবর্তী যেকোনও ভার্সনে, getPrimaryClipDescription()
নিম্নলিখিত বিবরণ শনাক্ত করতে পারে:
- স্টাইল যোগ করা টেক্সট,
isStyledText()ব্যবহার করে। getConfidenceScore()ব্যবহার করে URL-এর মতো টেক্সটের বিভিন্ন শ্রেণীবিভাগ।
অ্যাপ সিস্টেম ডায়ালগ বন্ধ করতে পারবে না
অ্যাপ ও সিস্টেমের সাথে ইন্টার্যাক্ট করার সময় ব্যবহারকারীর নিয়ন্ত্রণ উন্নত করতে, Android ১২ থেকে
ACTION_CLOSE_SYSTEM_DIALOGS
ইনটেন্ট অ্যাকশন বন্ধ করে দেওয়া হয়েছে। কয়েকটি
বিশেষ ক্ষেত্র ছাড়া, আপনার অ্যাপ যখন এই অ্যাকশন সহ ইনটেন্ট
ইনভোক করার চেষ্টা করে, তখন
সিস্টেম আপনার অ্যাপের টার্গেট SDK ভার্সনের উপর ভিত্তি করে নিম্নলিখিতগুলির মধ্যে একটি করে:
- আপনার অ্যাপ Android 12 বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করলে,
SecurityExceptionহয়। আপনার অ্যাপ Android 11 (API লেভেল 30) বা তার আগের কোনও ভার্সনকে টার্গেট করলে, ইনটেন্ট এক্সিকিউট হয় না এবং Logcat-এ নিম্নলিখিত মেসেজ দেখানো হয়:
E ActivityTaskManager Permission Denial: \ android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \ com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \ dropping broadcast.
ব্যতিক্রম
নিম্নলিখিত ক্ষেত্রে, কোনও অ্যাপ এখনও Android 12 বা তার পরবর্তী ভার্সনে সিস্টেম ডায়ালগ বন্ধ করতে পারে:
- আপনার অ্যাপে ইনস্ট্রুমেন্টেশন টেস্ট চলছে।
আপনার অ্যাপ Android 11 বা তার আগের যেকোনও ভার্সনকে টার্গেট করে এবং এমন একটি উইন্ডো দেখাচ্ছে যা বিজ্ঞপ্তি ড্রয়ারের উপরে রয়েছে।
আপনার অ্যাপ Android 11 বা তার আগের যেকোনও ভার্সনকে টার্গেট করে। এছাড়াও, ব্যবহারকারী কোনও বিজ্ঞপ্তির সাথে ইন্টার্যাক্ট করেছেন, সম্ভবত বিজ্ঞপ্তির অ্যাকশন বোতাম ব্যবহার করে এবং আপনার অ্যাপ ব্যবহারকারীর সেই অ্যাকশনের উত্তরে কোনও পরিষেবা বা সম্প্রচার রিসিভার প্রসেস করছে।
আপনার অ্যাপ Android 11 বা তার আগের যেকোনও ভার্সনকে টার্গেট করে এবং এতে একটি অ্যাক্টিভ অ্যাক্সেসিবিলিটি পরিষেবা আছে। আপনার অ্যাপ Android 12-কে টার্গেট করলে এবং বিজ্ঞপ্তি বার বন্ধ করতে চাইলে, পরিবর্তে
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADEঅ্যাক্সেসিবিলিটি অ্যাকশন ব্যবহার করুন।
অবিশ্বস্ত টাচ ইভেন্ট ব্লক করা হয়েছে
সিস্টেমের নিরাপত্তা ও ব্যবহারকারীর ভালো অভিজ্ঞতা বজায় রাখতে, Android 12 অ্যাপকে টাচ ইভেন্ট ব্যবহার করা থেকে আটকায় যেখানে ওভারলে অ্যাপকে অসুরক্ষিত উপায়ে অস্পষ্ট করে দেয়। অন্যভাবে বলতে গেলে, সিস্টেম নির্দিষ্ট উইন্ডোর মাধ্যমে পাস করা টাচ ব্লক করে, কিছু ব্যতিক্রম সহ।
প্রভাবিত অ্যাপ
এই পরিবর্তন সেইসব অ্যাপকে প্রভাবিত করে যেগুলি তাদের উইন্ডোর মাধ্যমে টাচ পাস করার বিকল্প বেছে নেয়,
যেমন
FLAG_NOT_TOUCHABLE
ফ্ল্যাগ ব্যবহার করে। এর কিছু উদাহরণ নিচে দেওয়া হল:
- ওভারলে যেগুলির জন্য
SYSTEM_ALERT_WINDOWঅনুমতি প্রয়োজন, যেমন উইন্ডো যেগুলিTYPE_APPLICATION_OVERLAYব্যবহার করে, এবংFLAG_NOT_TOUCHABLEফ্ল্যাগ ব্যবহার করে। - অ্যাক্টিভিটি উইন্ডো যা
FLAG_NOT_TOUCHABLEফ্ল্যাগ ব্যবহার করে।
ব্যতিক্রম
নিম্নলিখিত ক্ষেত্রে, "পাস-থ্রু" টাচ অনুমোদিত:
- আপনার অ্যাপের মধ্যে ইন্টার্যাকশন। আপনার অ্যাপ ওভারলে দেখায় এবং ব্যবহারকারী আপনার অ্যাপের সাথে ইন্টার্যাক্ট করলে তবেই ওভারলে দেখা যায়।
বিশ্বস্ত উইন্ডো। এইসব উইন্ডোর মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত (তবে এর মধ্যেই সীমাবদ্ধ নয়):
সম্পূর্ণ স্বচ্ছ জানলা। উইন্ডোর জন্য
alphaপ্রপার্টি 0.0।সিস্টেম সংক্রান্ত সতর্কতার উইন্ডো যথেষ্ট পরিমাণে ট্রান্সলুসেন্ট হতে হবে। সিস্টেম অ্যালার্ট উইন্ডোর সেটকে সিস্টেম যথেষ্ট স্বচ্ছ বলে বিবেচনা করে যখন সম্মিলিত অস্বচ্ছতা টাচের জন্য সিস্টেমের সর্বাধিক অস্পষ্ট অস্বচ্ছতার চেয়ে কম বা সমান হয়। Android 12-এ, ডিফল্ট হিসেবে এই সর্বাধিক অস্বচ্ছতা হল ০.৮।
অবিশ্বস্ত টাচ ব্লক করা হলে তা শনাক্ত করুন
সিস্টেম কোনও টাচ অ্যাকশন ব্লক করলে, Logcat নিম্নলিখিত মেসেজ লগ করে:
Untrusted touch due to occlusion by PACKAGE_NAME
পরিবর্তনটি পরীক্ষা করুন
Android 12 বা তার পরবর্তী ভার্সনে চলে এমন ডিভাইসে ডিফল্ট হিসেবে অবিশ্বস্ত টাচ ব্লক করা থাকে। অবিশ্বস্ত টাচকে অনুমতি দিতে, টার্মিনাল উইন্ডোতে নিম্নলিখিত ADB কমান্ড রান করুন:
# A specific app adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps # If you'd still like to see a Logcat message warning when a touch would be # blocked, use 1 instead of 0. adb shell settings put global block_untrusted_touches 0
আচরণটি ডিফল্টে ফিরিয়ে আনতে (অবিশ্বস্ত টাচ ব্লক করা হয়), নিম্নলিখিত কমান্ডটি রান করুন:
# A specific app adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps adb shell settings put global block_untrusted_touches 2
অ্যাক্টিভিটি লাইফসাইকেল
'ফিরে যান' বোতাম প্রেস করলে রুট লঞ্চার অ্যাক্টিভিটি আর শেষ হয় না
Android 12-এ লঞ্চার অ্যাক্টিভিটির ক্ষেত্রে সিস্টেমের 'ফিরে যান' বোতাম প্রেস করার ডিফল্ট হ্যান্ডলিং পরিবর্তন করা হয়েছে। এই অ্যাক্টিভিটিগুলি টাস্কের রুট লেভেলে থাকে। আগের ভার্সনে, 'ফিরে যান' বোতাম প্রেস করলে সিস্টেম এইসব অ্যাক্টিভিটি শেষ করে দিত। Android 12-এ, সিস্টেম এখন অ্যাক্টিভিটি শেষ করার পরিবর্তে অ্যাক্টিভিটি এবং এর টাস্ক ব্যাকগ্রাউন্ডে সরিয়ে দেয়। হোম বোতাম বা জেসচার ব্যবহার করে কোনও অ্যাপ থেকে বেরিয়ে আসার সময় নতুন আচরণ বর্তমান আচরণের সাথে মিলে যায়।
বেশিরভাগ অ্যাপের ক্ষেত্রে, এই পরিবর্তনের অর্থ হল, যেসব ব্যবহারকারী আপনার অ্যাপ থেকে বেরিয়ে আসার জন্য 'ফিরে যান' বোতাম ব্যবহার করেন, তারা কোল্ড স্টেট থেকে অ্যাপটি সম্পূর্ণভাবে রিস্টার্ট করার পরিবর্তে ওয়ার্ম স্টেট থেকে আপনার অ্যাপটি আরও দ্রুত আবার চালু করতে পারবেন।
এই পরিবর্তন সহ আপনার অ্যাপ পরীক্ষা করে দেখার জন্য আমরা সাজেস্ট করছি। আপনার অ্যাপ বর্তমানে ব্যাক নেভিগেশন ম্যানেজ করতে এবং Activity শেষ করতে
onBackPressed() ওভাররাইড করলে, শেষ করার পরিবর্তে super.onBackPressed()-এর মাধ্যমে কল করার জন্য আপনার ইমপ্লিমেন্টেশন আপডেট করুন। super.onBackPressed() কল করলে,
প্রয়োজন হলে, অ্যাক্টিভিটি ও তার টাস্ক ব্যাকগ্রাউন্ডে চলে যায় এবং
বিভিন্ন অ্যাপ জুড়ে ব্যবহারকারীদের আরও সামঞ্জস্যপূর্ণ নেভিগেশন অভিজ্ঞতা প্রদান করে।
এছাড়াও মনে রাখবেন যে, সাধারণত, আমরা onBackPressed() ওভাররাইড করার পরিবর্তে
কাস্টম ব্যাক নেভিগেশন প্রদান করার জন্য
AndroidX অ্যাক্টিভিটি API ব্যবহার করার সাজেশন দিই। সিস্টেমের 'ফিরে যান' প্রেস ইন্টারসেপ্ট করার মতো কোনও কম্পোনেন্ট না থাকলে,
AndroidX অ্যাক্টিভিটি API
অটোমেটিক উপযুক্ত সিস্টেম আচরণে ডিফার করে।
গ্রাফিক্স ও ছবি
উন্নত রিফ্রেশ রেট সুইচিং
Android 12-এ,
setFrameRate()
ব্যবহার করে রিফ্রেশ রেট পরিবর্তন করা যেতে পারে, ডিসপ্লে নতুন রিফ্রেশ রেটে সিমলেস ট্রানজিশন সাপোর্ট করে কিনা তা নির্বিশেষে; সিমলেস ট্রানজিশন হল এমন একটি ট্রানজিশন যাতে কোনও ভিজ্যুয়াল বাধা থাকে না, যেমন এক বা দুই সেকেন্ডের জন্য একটি কালো স্ক্রিন। আগে, ডিসপ্লেতে সিমলেস ট্রানজিশন কাজ না করলে, setFrameRate() কল করার পরেও সাধারণত একই রিফ্রেশ রেট ব্যবহার করা
অব্যাহত থাকত। getAlternativeRefreshRates() কল করে আপনি আগে থেকেই নির্ধারণ করতে পারবেন যে নতুন রিফ্রেশে ট্রানজিশন নির্বিঘ্ন হবে কিনা।
সাধারণত, রিফ্রেশ রেট সুইচ সম্পূর্ণ হওয়ার পরে কলব্যাক onDisplayChanged()
কল করা হয়, তবে কিছু এক্সটার্নাল কানেক্ট করা ডিসপ্লের ক্ষেত্রে, এটি নন-সিমলেস ট্রানজিশনের সময় কল করা হয়।
আপনি কীভাবে এটি প্রয়োগ করতে পারেন তার একটি উদাহরণ এখানে দেওয়া হল:
Kotlin
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. val refreshRates = this.display?.mode?.alternativeRefreshRates val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate) // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)
জাভা
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. Display display = context.getDisplay(); // API 30+ Display.Mode mode = display.getMode(); float[] refreshRates = mode.getAlternativeRefreshRates(); boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate); // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);
কানেক্টিভিটি
পাসপয়েন্ট আপডেট
Android 12-এ নিম্নলিখিত API যোগ করা হয়েছে:
isPasspointTermsAndConditionsSupported(): নিয়ম ও শর্তাবলী হল একটি Passpoint ফিচার যা নেটওয়ার্ক ডেপ্লয়মেন্টকে অসুরক্ষিত ক্যাপটিভ পোর্টাল, যা ওপেন নেটওয়ার্ক ব্যবহার করে, সেটিকে একটি সুরক্ষিত Passpoint নেটওয়ার্ক দিয়ে পরিবর্তন করার অনুমতি দেয়। নিয়ম ও শর্তাবলীতে সম্মতি জানানোর প্রয়োজন হলে, ব্যবহারকারীকে একটি বিজ্ঞপ্তি দেখানো হয়। যেসব অ্যাপ নিয়ম ও শর্তাবলী দ্বারা গেট করা পাসপয়েন্ট নেটওয়ার্কের সাজেশন দেয়, ডিভাইসটি এই ক্ষমতাকে সাপোর্ট করে কিনা তা নিশ্চিত করতে প্রথমে এই API-কে কল করতে হবে। ডিভাইসে এই ক্ষমতা না থাকলে, এটি এই নেটওয়ার্কে কানেক্ট করতে পারবে না এবং বিকল্প বা লিগ্যাসি নেটওয়ার্ক সাজেস্ট করতে হবে।isDecoratedIdentitySupported(): প্রিফিক্স ডেকোরেশন সহ নেটওয়ার্কে যাচাইকরণ করার সময়, ডেকোরেট করা আইডেন্টিটি প্রিফিক্স নেটওয়ার্ক অপারেটরকে নেটওয়ার্ক অ্যাক্সেস আইডেন্টিফায়ার (NAI) আপডেট করার অনুমতি দেয় যাতে AAA নেটওয়ার্কের মধ্যে একাধিক প্রক্সির মাধ্যমে এক্সপ্লিসিট রাউটিং করা যায় (এই বিষয়ে আরও জানতে RFC 7542 দেখুন)।PPS-MO এক্সটেনশনের জন্য WBA স্পেসিফিকেশন মেনে চলার জন্য Android 12 এই ফিচার প্রয়োগ করে। যেসব অ্যাপ পাসপয়েন্ট নেটওয়ার্ক সাজেস্ট করে এবং যেগুলির জন্য সাজানো পরিচয় প্রয়োজন, সেগুলিকে প্রথমে এই API কল করতে হবে যাতে ডিভাইসটি এই ক্ষমতা সমর্থন করে কিনা তা নিশ্চিত করা যায়। ডিভাইসে এই ক্ষমতা না থাকলে, পরিচয় ডেকোরেট করা হবে না এবং নেটওয়ার্কে যাচাইকরণ সম্পূর্ণ নাও হতে পারে।
পাসপয়েন্ট সাজেশন তৈরি করতে, অ্যাপকে অবশ্যই
PasspointConfiguration,
Credential এবং
HomeSp ক্লাস ব্যবহার করতে হবে। এই
ক্লাসগুলি পাসপয়েন্ট প্রোফাইল বর্ণনা করে, যা Wi-Fi Alliance
পাসপয়েন্ট
স্পেসিফিকেশনে সংজ্ঞায়িত করা হয়েছে।
আরও তথ্যের জন্য, ইন্টারনেট কানেক্টিভিটির জন্য ওয়াই-ফাই সাজেশন API দেখুন।
নন-SDK ইন্টারফেস সংক্রান্ত বিধিনিষেধ আপডেট করা হয়েছে
Android 12-এ Android ডেভেলপারদের সাথে সহযোগিতা এবং লেটেস্ট ইন্টার্নাল টেস্টিংয়ের উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত করা হয়েছে। যখনই সম্ভব, আমরা নিশ্চিত করি যে নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলভ্য আছে।
আপনার অ্যাপ Android ১২-কে টার্গেট না করলে, এইসব পরিবর্তনের মধ্যে কিছু আপনার উপর অবিলম্বে প্রভাব নাও ফেলতে পারে। তবে, বর্তমানে আপনি কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারলেও (আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে), যেকোনও নন-SDK পদ্ধতি বা ফিল্ড ব্যবহার করলে সবসময় আপনার অ্যাপ কাজ করা বন্ধ করে দেওয়ার ঝুঁকি থাকে।
আপনার অ্যাপ নন-SDK ইন্টারফেস ব্যবহার করে কিনা তা নিশ্চিত না হলে, আপনি আপনার অ্যাপ পরীক্ষা করে দেখতে পারেন। আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করলে, SDK বিকল্পে মাইগ্রেট করার পরিকল্পনা শুরু করা উচিত। তবে, আমরা বুঝি যে কিছু অ্যাপের ক্ষেত্রে SDK-বহির্ভূত ইন্টারফেস ব্যবহার করার বৈধ কারণ আছে। আপনার অ্যাপের কোনও ফিচারের জন্য নন-SDK ইন্টারফেস ব্যবহার করার বিকল্প খুঁজে না পেলে, আপনাকে নতুন পাবলিক API-এর জন্য অনুরোধ করতে হবে।
Android-এর এই রিলিজের পরিবর্তন সম্পর্কে আরও জানতে, Android 12-এ নন-SDK ইন্টারফেস সংক্রান্ত বিধিনিষেধের আপডেট দেখুন। সাধারণত নন-SDK ইন্টারফেস সম্পর্কে আরও জানতে, নন-SDK ইন্টারফেসের উপর বিধিনিষেধ দেখুন।