Android 12 প্ল্যাটফর্মে এমন আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণগত পরিবর্তনগুলি সমস্ত অ্যাপের ক্ষেত্রে প্রযোজ্য যখন তারা Android 12 এ চলে, targetSdkVersion নির্বিশেষে। আপনার অ্যাপটি পরীক্ষা করা উচিত এবং তারপরে প্রযোজ্য ক্ষেত্রে এগুলি সঠিকভাবে সমর্থন করার জন্য প্রয়োজন অনুসারে এটি পরিবর্তন করা উচিত।
শুধুমাত্র Android 12-কে লক্ষ্য করে এমন অ্যাপগুলিকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।
ব্যবহারকারীর অভিজ্ঞতা
ওভারস্ক্রোল এফেক্ট প্রসারিত করুন
অ্যান্ড্রয়েড ১২ এবং তার পরবর্তী ভার্সন চালিত ডিভাইসগুলিতে, ওভারস্ক্রোল ইভেন্টের ভিজ্যুয়াল আচরণ পরিবর্তিত হয়।
অ্যান্ড্রয়েড ১১ এবং তার নিচের ভার্সনে, একটি ওভারস্ক্রোল ইভেন্ট ভিজ্যুয়াল এলিমেন্টগুলিকে একটি উজ্জ্বলতা দেয়; অ্যান্ড্রয়েড ১২ এবং তার উপরের ভার্সনে, ভিজ্যুয়াল এলিমেন্টগুলি একটি ড্র্যাগ ইভেন্টে প্রসারিত হয় এবং ফিরে আসে এবং তারা একটি ফ্লিং ইভেন্টে ফিরে আসে।
আরও তথ্যের জন্য, স্ক্রোল জেসচার অ্যানিমেট করার নির্দেশিকাটি দেখুন।
অ্যাপ স্প্ল্যাশ স্ক্রিন
যদি আপনি আগে অ্যান্ড্রয়েড ১১ বা তার আগের ভার্সনে একটি কাস্টম স্প্ল্যাশ স্ক্রিন প্রয়োগ করে থাকেন, তাহলে অ্যান্ড্রয়েড ১২ থেকে শুরু করে সঠিকভাবে প্রদর্শিত হচ্ছে কিনা তা নিশ্চিত করার জন্য আপনাকে আপনার অ্যাপটিকে SplashScreen API-তে স্থানান্তর করতে হবে। আপনার অ্যাপটি স্থানান্তর না করলে অ্যাপ লঞ্চের অভিজ্ঞতা হ্রাস পাবে বা অনিচ্ছাকৃত হবে।
নির্দেশাবলীর জন্য, আপনার বিদ্যমান স্প্ল্যাশ স্ক্রিন বাস্তবায়নকে Android 12 এ স্থানান্তর করুন দেখুন।
এছাড়াও, অ্যান্ড্রয়েড ১২ থেকে শুরু করে, সিস্টেমটি সর্বদা সমস্ত অ্যাপের জন্য ঠান্ডা এবং উষ্ণ শুরুতে নতুন অ্যান্ড্রয়েড সিস্টেম ডিফল্ট স্প্ল্যাশ স্ক্রিন প্রয়োগ করে। ডিফল্টরূপে, এই সিস্টেম ডিফল্ট স্প্ল্যাশ স্ক্রিনটি আপনার অ্যাপের লঞ্চার আইকন উপাদান এবং আপনার থিমের windowBackground (যদি এটি একটি একক রঙের হয়) ব্যবহার করে তৈরি করা হয়।
আরও বিস্তারিত জানার জন্য, স্প্ল্যাশ স্ক্রিন ডেভেলপার গাইড দেখুন।
ওয়েব ইন্টেন্ট রেজোলিউশন
অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) থেকে শুরু করে, একটি জেনেরিক ওয়েব ইন্টেন্ট আপনার অ্যাপের কোনও অ্যাক্টিভিটিতে তখনই সমাধান করা হয় যখন আপনার অ্যাপটি সেই ওয়েব ইন্টেন্টে থাকা নির্দিষ্ট ডোমেনের জন্য অনুমোদিত হয়। যদি আপনার অ্যাপটি ডোমেনের জন্য অনুমোদিত না হয়, তাহলে ওয়েব ইন্টেন্টটি ব্যবহারকারীর ডিফল্ট ব্রাউজার অ্যাপে সমাধান করা হয়।
অ্যাপগুলি নিম্নলিখিত যেকোনো একটি করে এই অনুমোদন পেতে পারে:
অ্যান্ড্রয়েড অ্যাপ লিংক ব্যবহার করে ডোমেইন যাচাই করুন।
যেসব অ্যাপ অ্যান্ড্রয়েড ১২ বা তার পরবর্তী ভার্সনের জন্য কাজ করে, সেসব অ্যাপের ক্ষেত্রে সিস্টেম আপনার অ্যাপের অ্যান্ড্রয়েড অ্যাপ লিঙ্কগুলি স্বয়ংক্রিয়ভাবে যাচাই করার পদ্ধতি পরিবর্তন করে। আপনার অ্যাপের ইন্টেন্ট ফিল্টারগুলিতে , আপনি
BROWSABLEবিভাগটি অন্তর্ভুক্ত করেছেন কিনা এবংhttpsস্কিম সমর্থন করছেন কিনা তা পরীক্ষা করে দেখুন।অ্যান্ড্রয়েড ১২ বা তার পরবর্তী ভার্সনে, আপনি আপনার অ্যাপের অ্যান্ড্রয়েড অ্যাপ লিঙ্কগুলি ম্যানুয়ালি যাচাই করতে পারেন, এই আপডেট করা লজিকটি আপনার অ্যাপকে কীভাবে প্রভাবিত করে তা পরীক্ষা করতে।
সিস্টেম সেটিংসে ব্যবহারকারীকে আপনার অ্যাপটি ডোমেনের সাথে সংযুক্ত করার জন্য অনুরোধ করুন ।
যদি আপনার অ্যাপটি ওয়েব ইন্টেন্ট ব্যবহার করে, তাহলে একটি প্রম্পট বা ডায়ালগ যোগ করার কথা বিবেচনা করুন যা ব্যবহারকারীকে ক্রিয়াটি নিশ্চিত করতে বলে।
অঙ্গভঙ্গি নেভিগেশনের জন্য ইমারসিভ মোডের উন্নতি
অ্যান্ড্রয়েড ১২ ব্যবহারকারীদের জন্য ইমারসিভ মোডে থাকাকালীন জেসচার নেভিগেশন কমান্ড সম্পাদন করা সহজ করার জন্য বিদ্যমান আচরণকে একীভূত করে। এছাড়াও, অ্যান্ড্রয়েড ১২ স্টিকি ইমারসিভ মোডের জন্য ব্যাকওয়ার্ড সামঞ্জস্যতা আচরণ প্রদান করে।
Display#getRealSize এবং getRealMetrics: অবচয় এবং সীমাবদ্ধতা
অ্যান্ড্রয়েড ডিভাইসগুলি বিভিন্ন ফর্ম ফ্যাক্টরে পাওয়া যায়, যেমন বড় স্ক্রিন, ট্যাবলেট এবং ফোল্ডেবল। প্রতিটি ডিভাইসের জন্য উপযুক্তভাবে কন্টেন্ট রেন্ডার করার জন্য, আপনার অ্যাপকে স্ক্রিন বা ডিসপ্লের আকার নির্ধারণ করতে হবে। সময়ের সাথে সাথে, অ্যান্ড্রয়েড এই তথ্য পুনরুদ্ধারের জন্য বিভিন্ন API প্রদান করেছে। অ্যান্ড্রয়েড ১১-এ, আমরা WindowMetrics API চালু করেছি এবং এই পদ্ধতিগুলি বন্ধ করে দিয়েছি:
অ্যান্ড্রয়েড ১২-তে আমরা WindowMetrics ব্যবহার করার পরামর্শ দিচ্ছি এবং এই পদ্ধতিগুলি অবমূল্যায়ন করছি:
ডিসপ্লে এপিআই ব্যবহার করে অ্যাপ্লিকেশনের সীমা পুনরুদ্ধারের আচরণ কমাতে, অ্যান্ড্রয়েড ১২ সম্পূর্ণরূপে আকার পরিবর্তনযোগ্য নয় এমন অ্যাপগুলির জন্য এপিআই দ্বারা ফেরত দেওয়া মানগুলিকে সীমাবদ্ধ করে। এটি MediaProjection সাথে এই তথ্য ব্যবহার করা অ্যাপগুলির উপর প্রভাব ফেলতে পারে।
অ্যাপগুলিকে তাদের উইন্ডোর সীমানা অনুসন্ধানের জন্য WindowMetrics API ব্যবহার করতে হবে, এবং বর্তমান ঘনত্ব অনুসন্ধানের জন্য Configuration.densityDpi ব্যবহার করতে হবে।
অ্যান্ড্রয়েডের পুরোনো সংস্করণগুলির সাথে আরও বিস্তৃত সামঞ্জস্যের জন্য, আপনি জেটপ্যাক WindowManager লাইব্রেরি ব্যবহার করতে পারেন, যার মধ্যে একটি WindowMetrics ক্লাস রয়েছে যা অ্যান্ড্রয়েড 4.0 (API স্তর 14) এবং উচ্চতর সংস্করণ সমর্থন করে।
WindowMetrics ব্যবহারের উদাহরণ
প্রথমে, নিশ্চিত করুন যে আপনার অ্যাপের কার্যকলাপগুলি সম্পূর্ণরূপে আকার পরিবর্তনযোগ্য ।
কোনও UI-সম্পর্কিত কাজের জন্য, বিশেষ করে WindowManager.getCurrentWindowMetrics() অথবা Jetpack-এর WindowMetricsCalculator.computeCurrentWindowMetrics() , কোনও অ্যাক্টিভিটির প্রেক্ষাপট থেকে WindowMetrics উপর নির্ভর করা উচিত।
যদি আপনার অ্যাপটি একটি MediaProjection তৈরি করে, তাহলে সীমানাগুলি সঠিকভাবে মাপ দিতে হবে কারণ প্রজেক্টর অ্যাপটি যে ডিসপ্লে পার্টিশনে চলছে সেটিকে প্রজেক্টর ক্যাপচার করে।
যদি অ্যাপটি সম্পূর্ণরূপে আকার পরিবর্তনযোগ্য হয়, তাহলে কার্যকলাপ প্রসঙ্গটি সঠিক সীমানা প্রদান করে যেমন:
কোটলিন
val projectionMetrics: WindowMetrics = activityContext .getSystemService(WindowManager::class.java).maximumWindowMetrics
জাভা
WindowMetrics projectionMetrics = activityContext .getSystemService(WindowManager.class).getMaximumWindowMetrics();
যদি অ্যাপটি সম্পূর্ণরূপে আকার পরিবর্তনযোগ্য না হয়, তাহলে এটিকে একটি WindowContext ইনস্ট্যান্স থেকে কোয়েরি করতে হবে এবং WindowManager.getMaximumWindowMetrics() অথবা Jetpack পদ্ধতি WindowMetricsCalculator.computeMaximumWindowMetrics() ব্যবহার করে কার্যকলাপ সীমার WindowMetrics পুনরুদ্ধার করতে হবে।
কোটলিন
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();
মাল্টি-উইন্ডো মোডে সমস্ত অ্যাপ
অ্যান্ড্রয়েড ১২ মাল্টি-উইন্ডো মোডকে স্ট্যান্ডার্ড আচরণ করে।
বড় স্ক্রিনে (sw >= 600dp), প্ল্যাটফর্মটি অ্যাপ কনফিগারেশন নির্বিশেষে মাল্টি-উইন্ডো মোডে সমস্ত অ্যাপ সমর্থন করে। যদি resizeableActivity="false" হয়, তাহলে ডিসপ্লের মাত্রা সামঞ্জস্য করার জন্য প্রয়োজনে অ্যাপটিকে সামঞ্জস্য মোডে রাখা হয়।
ছোট স্ক্রিনে (sw < 600dp), সিস্টেমটি একটি অ্যাক্টিভিটির minWidth এবং minHeight পরীক্ষা করে নির্ধারণ করে যে অ্যাক্টিভিটিটি মাল্টি-উইন্ডো মোডে চালানো যাবে কিনা। যদি resizeableActivity="false" হয়, তাহলে অ্যাপটি ন্যূনতম প্রস্থ এবং উচ্চতা নির্বিশেষে মাল্টি-উইন্ডো মোডে চালানো থেকে বিরত থাকে।
আরও তথ্যের জন্য, মাল্টি-উইন্ডো সাপোর্ট দেখুন।
বড় স্ক্রিনে ক্যামেরা প্রিভিউ
ক্যামেরা অ্যাপগুলি সাধারণত ডিভাইসের ওরিয়েন্টেশন এবং ক্যামেরা প্রিভিউয়ের আকৃতির অনুপাতের মধ্যে একটি স্থির সম্পর্ক ধরে নেয়। কিন্তু ভাঁজযোগ্য ডিভাইসের মতো বড় স্ক্রিন ফর্ম ফ্যাক্টর এবং মাল্টি-উইন্ডো এবং মাল্টি-ডিসপ্লের মতো ডিসপ্লে মোডগুলি এই ধারণাকে চ্যালেঞ্জ করে।
অ্যান্ড্রয়েড ১২-তে, যেসব ক্যামেরা অ্যাপ নির্দিষ্ট স্ক্রিন ওরিয়েন্টেশনের অনুরোধ করে এবং রিসাইজেবল resizeableActivity="false" ) নয়, তারা স্বয়ংক্রিয়ভাবে ইনসেট পোর্ট্রেট মোডে প্রবেশ করে, যা ক্যামেরা প্রিভিউয়ের সঠিক ওরিয়েন্টেশন এবং অ্যাসপেক্ট রেশিও নিশ্চিত করে। ফোল্ডেবল এবং অন্যান্য ডিভাইসে যেখানে ক্যামেরা হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার ( HAL ) আছে, ক্যামেরা সেন্সর ওরিয়েন্টেশনের জন্য ক্ষতিপূরণ দেওয়ার জন্য ক্যামেরা আউটপুটে অতিরিক্ত ঘূর্ণন প্রয়োগ করা হয় এবং অ্যাপের ক্যামেরা প্রিভিউয়ের অ্যাসপেক্ট রেশিওর সাথে মেলে ক্যামেরা আউটপুট ক্রপ করা হয়। ক্রপিং এবং অতিরিক্ত ঘূর্ণন ডিভাইসের ওরিয়েন্টেশন এবং ভাঁজ করা বা খোলা অবস্থা নির্বিশেষে ক্যামেরা প্রিভিউয়ের সঠিক উপস্থাপনা নিশ্চিত করে।
ফোরগ্রাউন্ড পরিষেবা বিজ্ঞপ্তির জন্য UX বিলম্ব
স্বল্প-স্থায়ী ফোরগ্রাউন্ড পরিষেবাগুলির জন্য একটি সুবিন্যস্ত অভিজ্ঞতা প্রদানের জন্য, Android 12 বা উচ্চতর সংস্করণ চালিত ডিভাইসগুলি কয়েকটি ব্যতিক্রম ছাড়া, ফোরগ্রাউন্ড পরিষেবা বিজ্ঞপ্তিগুলির প্রদর্শন 10 সেকেন্ড বিলম্বিত করতে পারে। এই পরিবর্তনটি স্বল্প-স্থায়ী কাজগুলিকে তাদের বিজ্ঞপ্তিগুলি প্রদর্শিত হওয়ার আগে সম্পূর্ণ করার সুযোগ দেয়।
কর্মক্ষমতা
সীমাবদ্ধ অ্যাপ স্ট্যান্ডবাই বাকেট
অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) অ্যাপ স্ট্যান্ডবাই বাকেট হিসেবে সীমাবদ্ধ বাকেট চালু করেছে। অ্যান্ড্রয়েড ১২ থেকে শুরু করে, এই বাকেটটি ডিফল্টরূপে সক্রিয় থাকে। সীমাবদ্ধ বাকেটটি সমস্ত বাকেটের মধ্যে সর্বনিম্ন অগ্রাধিকার (এবং সর্বোচ্চ সীমাবদ্ধতা) রাখে। উচ্চ থেকে নিম্ন পর্যন্ত অগ্রাধিকারের ক্রম অনুসারে বাকেটগুলি হল:
- সক্রিয়: অ্যাপটি বর্তমানে ব্যবহৃত হচ্ছে অথবা খুব সম্প্রতি ব্যবহৃত হয়েছে।
- কাজের সেট: অ্যাপটি নিয়মিত ব্যবহার করা হচ্ছে।
- ঘন ঘন: অ্যাপটি প্রায়শই ব্যবহৃত হয়, তবে প্রতিদিন নয়।
- বিরল: অ্যাপটি প্রায়শই ব্যবহৃত হয় না।
- সীমাবদ্ধ: অ্যাপটি প্রচুর পরিমাণে সিস্টেম রিসোর্স ব্যবহার করে, অথবা অবাঞ্ছিত আচরণ প্রদর্শন করতে পারে।
আপনার অ্যাপটিকে সীমাবদ্ধ বাকেটে রাখা হবে কিনা তা নির্ধারণ করার জন্য সিস্টেমটি ব্যবহারের ধরণ ছাড়াও আপনার অ্যাপের আচরণ বিবেচনা করে।
যদি আপনার অ্যাপটি সিস্টেম রিসোর্সগুলিকে আরও দায়িত্বশীলতার সাথে ব্যবহার করে তবে আপনার অ্যাপটি সীমাবদ্ধ বাকেটে রাখার সম্ভাবনা কম থাকে। এছাড়াও, ব্যবহারকারী যদি সরাসরি আপনার অ্যাপের সাথে যোগাযোগ করে তবে সিস্টেমটি আপনার অ্যাপটিকে কম সীমাবদ্ধ বাকেটে রাখে।
আপনার অ্যাপটি সীমাবদ্ধ বাকেটে আছে কিনা তা পরীক্ষা করুন।
সিস্টেমটি আপনার অ্যাপটিকে সীমাবদ্ধ বাকেটে রেখেছে কিনা তা পরীক্ষা করতে, getAppStandbyBucket() কল করুন। যদি এই পদ্ধতির রিটার্ন মান STANDBY_BUCKET_RESTRICTED হয়, তাহলে আপনার অ্যাপটি সীমাবদ্ধ বাকেটে রয়েছে।
সীমাবদ্ধ বাকেট আচরণ পরীক্ষা করুন
সিস্টেম যখন আপনার অ্যাপটিকে সীমাবদ্ধ বাকেটে রাখে তখন আপনার অ্যাপটি কেমন আচরণ করে তা পরীক্ষা করার জন্য, আপনি ম্যানুয়ালি আপনার অ্যাপটিকে সেই বাকেটে স্থানান্তর করতে পারেন। এটি করার জন্য, একটি টার্মিনাল উইন্ডোতে নিম্নলিখিত কমান্ডটি চালান:
adb shell am set-standby-bucket PACKAGE_NAME restricted
ফোরগ্রাউন্ড লোকেশন এবং ব্যাটারি সেভার
অ্যান্ড্রয়েড ১২ থেকে শুরু করে, ব্যাটারি সেভার সক্রিয় থাকাকালীন, এমনকি স্ক্রিন বন্ধ থাকাকালীনও, ফোরগ্রাউন্ড লোকেশন (ফোরগ্রাউন্ড পরিষেবা সহ) সরবরাহ করা যেতে পারে।
পূর্বে, ব্যাটারি সেভার মোড স্ক্রিন বন্ধ থাকাকালীন লোকেশন আপডেট বন্ধ করে দিত। এই পরিবর্তন ব্যবহারকারীদের জন্য আরও ভাল ব্যাটারি লাইফ সক্ষম করে এবং এর অর্থ হল ডেভেলপাররা লোকেশন ডেলিভারি নিশ্চিত করার জন্য ব্যবহারকারীদের ব্যাটারি সেভার অক্ষম করতে বলা থেকে বিরত থাকতে পারে।
যেসব অ্যাপ ফোরগ্রাউন্ড সার্ভিসের মাধ্যমে লোকেশনের অনুরোধ করে তাদের নিম্নলিখিত পদক্ষেপগুলি গ্রহণ করা উচিত:
- ব্যাটারি সেভার সক্রিয় থাকাকালীন ডিভাইসের লোকেশন বৈশিষ্ট্যগুলি কীভাবে আচরণ করে তা পরীক্ষা করতে
getLocationPowerSaverMode()এ কল করুন। - যদি এটি
LOCATION_MODE_FOREGROUND_ONLYফেরত দেয়, তাহলে আপনার অ্যাপটি ফোরগ্রাউন্ডে থাকাকালীন বা ব্যাটারি সেভার চালু থাকাকালীন এবং স্ক্রিন বন্ধ থাকাকালীন ফোরগ্রাউন্ড পরিষেবা চালানোর সময় অবস্থানের আপডেট পেতে থাকবে।
নিরাপত্তা এবং গোপনীয়তা
আনুমানিক অবস্থান
অ্যান্ড্রয়েড ১২ বা তার পরবর্তী ভার্সন চালানো ডিভাইসগুলিতে, ব্যবহারকারীরা আপনার অ্যাপের কাছে শুধুমাত্র আনুমানিক অবস্থানের তথ্য অ্যাক্সেস করার অনুরোধ করতে পারেন ।
যদি আপনার অ্যাপটি ACCESS_FINE_LOCATION রানটাইম অনুমতির জন্য অনুরোধ করে, তাহলে ব্যবহারকারী আপনার অ্যাপে আনুমানিক অবস্থান অ্যাক্সেস মঞ্জুর করলে সেই ক্ষেত্রেও আপনাকে ACCESS_COARSE_LOCATION অনুমতির জন্য অনুরোধ করতে হবে। আপনার একটি একক রানটাইম অনুরোধে উভয় অনুমতি অন্তর্ভুক্ত করা উচিত।
সিস্টেম অনুমতি সংলাপে ব্যবহারকারীর জন্য নিম্নলিখিত বিকল্পগুলি অন্তর্ভুক্ত রয়েছে, যেমন চিত্র 1 এ দেখানো হয়েছে:
- সুনির্দিষ্ট : সুনির্দিষ্ট অবস্থানের তথ্যে অ্যাক্সেস প্রদান করে।
- আনুমানিক : শুধুমাত্র আনুমানিক অবস্থানের তথ্যে অ্যাক্সেস প্রদান করে।
মাইক্রোফোন এবং ক্যামেরা টগল
অ্যান্ড্রয়েড ১২ বা তার পরবর্তী ভার্সন চালিত সমর্থিত ডিভাইসগুলি ব্যবহারকারীদের একটি একক টগল বিকল্প টিপে ডিভাইসের সমস্ত অ্যাপের জন্য ক্যামেরা এবং মাইক্রোফোন অ্যাক্সেস সক্ষম এবং অক্ষম করতে দেয়। ব্যবহারকারীরা চিত্র ১-এ দেখানো কুইক সেটিংস থেকে অথবা সিস্টেম সেটিংসের গোপনীয়তা স্ক্রিন থেকে টগলযোগ্য বিকল্পগুলি অ্যাক্সেস করতে পারেন।
এই টগলগুলি সম্পর্কে আরও জানুন, এবং আপনার অ্যাপটি CAMERA এবং RECORD_AUDIO অনুমতি সম্পর্কিত সর্বোত্তম অনুশীলনগুলি অনুসরণ করে কিনা তা কীভাবে পরীক্ষা করবেন তা জানুন।
মাইক্রোফোন এবং ক্যামেরা সূচক
অ্যান্ড্রয়েড ১২ বা তার পরবর্তী ভার্সন চালিত ডিভাইসগুলিতে, যখন কোনও অ্যাপ মাইক্রোফোন বা ক্যামেরা অ্যাক্সেস করে, তখন স্ট্যাটাস বারে একটি আইকন দেখা যায়।
এই সূচকগুলি সম্পর্কে আরও জানুন এবং আপনার অ্যাপটি CAMERA এবং RECORD_AUDIO অনুমতি সম্পর্কিত সর্বোত্তম অনুশীলনগুলি অনুসরণ করে কিনা তা কীভাবে পরীক্ষা করবেন তা জানুন।
অনুমতি প্যাকেজের দৃশ্যমানতা
যেসব ডিভাইসে অ্যান্ড্রয়েড ১২ বা তার উচ্চতর ভার্সন চলে, যেসব অ্যাপ অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) বা তার উচ্চতর ভার্সনকে লক্ষ্য করে এবং যেগুলো নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটিতে কল করে, তারা অন্যান্য অ্যাপে অ্যাপের প্যাকেজ দৃশ্যমানতার উপর ভিত্তি করে ফিল্টার করা ফলাফলের একটি সেট পায়:
BouncyCastle বাস্তবায়ন সরানো হয়েছে
অ্যান্ড্রয়েড ১২, পূর্বে বাতিল করা ক্রিপ্টোগ্রাফিক অ্যালগরিদমের অনেক BouncyCastle বাস্তবায়ন সরিয়ে দেয়, যার মধ্যে সমস্ত AES অ্যালগরিদমও রয়েছে। পরিবর্তে সিস্টেমটি এই অ্যালগরিদমগুলির Conscrypt বাস্তবায়ন ব্যবহার করে।
নিম্নলিখিতগুলির মধ্যে যদি কোনওটি সত্য হয় তবে এই পরিবর্তনটি আপনার অ্যাপকে প্রভাবিত করবে:
- আপনার অ্যাপটি ৫১২-বিট কী সাইজ ব্যবহার করে। কনস্ক্রিপ্ট এই কী সাইজ সাপোর্ট করে না। প্রয়োজনে, বিভিন্ন কী সাইজ ব্যবহার করার জন্য আপনার অ্যাপের ক্রিপ্টোগ্রাফি লজিক আপডেট করুন।
আপনার অ্যাপ
KeyGeneratorসাথে অবৈধ কী আকার ব্যবহার করে। BouncyCastle এর তুলনায় Conscrypt এরKeyGeneratorবাস্তবায়ন কী প্যারামিটারগুলিতে অতিরিক্ত যাচাইকরণ করে। উদাহরণস্বরূপ, Conscrypt আপনার অ্যাপকে 64-বিট AES কী তৈরি করতে দেয় না কারণ AES শুধুমাত্র 128-, 192- এবং 256-বিট কী সমর্থন করে।BouncyCastle অবৈধ আকারের কী তৈরি করার অনুমতি দেয়, কিন্তু পরে যদি এই কীগুলি
Cipherএর সাথে ব্যবহার করা হয় তবে তা ব্যর্থ হয়। Conscrypt আগে ব্যর্থ হয়।আপনি আপনার গ্যালোইস/কাউন্টার মোড (GCM) সাইফারগুলিকে ১২ বাইট ব্যতীত অন্য আকার ব্যবহার করে ইনিশিয়ালাইজ করেন। কনস্ক্রিপ্টের
GcmParameterSpecবাস্তবায়নের জন্য ১২ বাইট ইনিশিয়ালাইজেশন প্রয়োজন, যা NIST সুপারিশ করে।
ক্লিপবোর্ড অ্যাক্সেস বিজ্ঞপ্তি
অ্যান্ড্রয়েড ১২ এবং তার পরবর্তী ভার্সনে, যখন কোনও অ্যাপ প্রথমবারের মতো অন্য কোনও অ্যাপ থেকে ক্লিপ ডেটা অ্যাক্সেস করার জন্য getPrimaryClip() কল করে, তখন একটি টোস্ট বার্তা ব্যবহারকারীকে এই ক্লিপবোর্ড অ্যাক্সেস সম্পর্কে অবহিত করে।
টোস্ট বার্তার ভিতরের লেখাটিতে নিম্নলিখিত ফর্ম্যাটটি রয়েছে: APP pasted from your clipboard.
ক্লিপের বর্ণনায় লেখা সম্পর্কে তথ্য
অ্যান্ড্রয়েড ১২ এবং তার পরবর্তী ভার্সনে, getPrimaryClipDescription() নিম্নলিখিত বিবরণগুলি সনাক্ত করতে পারে:
- স্টাইলাইজড টেক্সট,
isStyledText()ব্যবহার করে। -
getConfidenceScore()ব্যবহার করে টেক্সটের বিভিন্ন শ্রেণীবিভাগ, যেমন URL।
অ্যাপগুলি সিস্টেম ডায়ালগ বন্ধ করতে পারছে না
অ্যাপ এবং সিস্টেমের সাথে ইন্টারঅ্যাক্ট করার সময় ব্যবহারকারীর নিয়ন্ত্রণ উন্নত করার জন্য, ACTION_CLOSE_SYSTEM_DIALOGS ইন্টেন্ট অ্যাকশনটি Android 12 থেকে বন্ধ করা হয়েছে । কয়েকটি বিশেষ ক্ষেত্রে বাদে, যখন আপনার অ্যাপ এই অ্যাকশন ধারণকারী একটি ইন্টেন্ট চালু করার চেষ্টা করে, তখন সিস্টেমটি আপনার অ্যাপের টার্গেট 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 12 কে টার্গেট করে এবং নোটিফিকেশন বারটি বন্ধ করতে চায়, তাহলে
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADEঅ্যাক্সেসিবিলিটি অ্যাকশনটি ব্যবহার করুন।
অবিশ্বস্ত স্পর্শ ইভেন্টগুলি ব্লক করা হয়েছে
সিস্টেমের নিরাপত্তা এবং ভালো ব্যবহারকারীর অভিজ্ঞতা বজায় রাখার জন্য, অ্যান্ড্রয়েড ১২ অ্যাপগুলিকে স্পর্শ ইভেন্ট ব্যবহার করতে বাধা দেয় যেখানে একটি ওভারলে অ্যাপটিকে অনিরাপদ উপায়ে অস্পষ্ট করে। অন্য কথায়, সিস্টেম কিছু ব্যতিক্রম ছাড়া নির্দিষ্ট উইন্ডোর মধ্য দিয়ে যাওয়া স্পর্শগুলিকে ব্লক করে।
প্রভাবিত অ্যাপ
এই পরিবর্তনটি সেইসব অ্যাপগুলিকে প্রভাবিত করে যারা তাদের উইন্ডো দিয়ে স্পর্শ করতে দেয়, উদাহরণস্বরূপ FLAG_NOT_TOUCHABLE ফ্ল্যাগ ব্যবহার করে। বেশ কয়েকটি উদাহরণের মধ্যে রয়েছে, তবে সীমাবদ্ধ নয়, নিম্নলিখিতগুলি:
- যেসব ওভারলে
SYSTEM_ALERT_WINDOWঅনুমতির প্রয়োজন হয়, যেমন যেসব উইন্ডোজTYPE_APPLICATION_OVERLAYব্যবহার করে এবংFLAG_NOT_TOUCHABLEফ্ল্যাগ ব্যবহার করে। -
FLAG_NOT_TOUCHABLEপতাকা ব্যবহার করে এমন কার্যকলাপ উইন্ডো।
ব্যতিক্রম
নিম্নলিখিত ক্ষেত্রে, "পাস-থ্রু" স্পর্শ অনুমোদিত:
- আপনার অ্যাপের মধ্যে ইন্টারঅ্যাকশন। আপনার অ্যাপ ওভারলে দেখায়, এবং ওভারলে তখনই প্রদর্শিত হয় যখন ব্যবহারকারী আপনার অ্যাপের সাথে ইন্টারঅ্যাক্ট করেন।
বিশ্বস্ত উইন্ডোজ। এই উইন্ডোগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত (কিন্তু সীমাবদ্ধ নয়):
সম্পূর্ণ স্বচ্ছ জানালা। জানালার জন্য
alphaবৈশিষ্ট্য হল 0.0।পর্যাপ্ত পরিমাণে স্বচ্ছ সিস্টেম সতর্কতা উইন্ডো। যখন সম্মিলিত অস্বচ্ছতা স্পর্শের জন্য সিস্টেমের সর্বাধিক অস্পষ্ট অস্বচ্ছতার চেয়ে কম বা সমান হয়, তখন সিস্টেমটি সিস্টেম সতর্কতা উইন্ডোগুলির একটি সেটকে যথেষ্ট স্বচ্ছ বলে মনে করে। অ্যান্ড্রয়েড 12-তে, এই সর্বোচ্চ অস্বচ্ছতা ডিফল্টরূপে 0.8।
অবিশ্বস্ত স্পর্শ কখন ব্লক করা হয়েছে তা সনাক্ত করুন
যদি সিস্টেম দ্বারা কোনও টাচ অ্যাকশন ব্লক করা হয়, তাহলে লগক্যাট নিম্নলিখিত বার্তাটি লগ করে:
Untrusted touch due to occlusion by PACKAGE_NAME
পরিবর্তনটি পরীক্ষা করুন
অ্যান্ড্রয়েড ১২ বা তার পরবর্তী ভার্সন চালিত ডিভাইসগুলিতে অবিশ্বস্ত স্পর্শগুলি ডিফল্টরূপে ব্লক করা থাকে। অবিশ্বস্ত স্পর্শগুলিকে অনুমতি দিতে, টার্মিনাল উইন্ডোতে নিম্নলিখিত 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
কার্যকলাপের জীবনচক্র
রুট লঞ্চার কার্যক্রম আর ব্যাক প্রেসে শেষ হয় না।
অ্যান্ড্রয়েড ১২, লঞ্চার অ্যাক্টিভিটিগুলির মূলে থাকা ব্যাক প্রেস সিস্টেমের ডিফল্ট হ্যান্ডলিং পরিবর্তন করে। পূর্ববর্তী সংস্করণগুলিতে, সিস্টেমটি ব্যাক প্রেসে এই অ্যাক্টিভিটিগুলি শেষ করত। অ্যান্ড্রয়েড ১২-তে, সিস্টেমটি এখন অ্যাক্টিভিটি শেষ করার পরিবর্তে অ্যাক্টিভিটি এবং এর টাস্কটিকে ব্যাকগ্রাউন্ডে সরিয়ে দেয়। হোম বোতাম বা অঙ্গভঙ্গি ব্যবহার করে কোনও অ্যাপ থেকে নেভিগেট করার সময় নতুন আচরণটি বর্তমান আচরণের সাথে মিলে যায়।
বেশিরভাগ অ্যাপের ক্ষেত্রে, এই পরিবর্তনের অর্থ হল যে ব্যবহারকারীরা আপনার অ্যাপ থেকে নেভিগেট করার জন্য Back ব্যবহার করেন তারা ঠান্ডা অবস্থা থেকে অ্যাপটি সম্পূর্ণরূপে পুনরায় চালু করার পরিবর্তে, উষ্ণ অবস্থা থেকে আপনার অ্যাপটি আরও দ্রুত পুনরায় চালু করতে সক্ষম হবেন।
আমরা এই পরিবর্তনটি ব্যবহার করে আপনার অ্যাপগুলি পরীক্ষা করার পরামর্শ দিচ্ছি। যদি আপনার অ্যাপটি বর্তমানে Back নেভিগেশন পরিচালনা করতে এবং Activity শেষ করতে onBackPressed() ওভাররাইড করে, তাহলে শেষ করার পরিবর্তে super.onBackPressed() এ কল করার জন্য আপনার বাস্তবায়ন আপডেট করুন। super.onBackPressed() কল করলে অ্যাক্টিভিটি এবং এর কাজটি উপযুক্ত হলে ব্যাকগ্রাউন্ডে চলে যায় এবং অ্যাপ জুড়ে ব্যবহারকারীদের জন্য আরও সামঞ্জস্যপূর্ণ নেভিগেশন অভিজ্ঞতা প্রদান করে।
আরও মনে রাখবেন যে, সাধারণভাবে, আমরা onBackPressed() ওভাররাইড করার পরিবর্তে কাস্টম ব্যাক নেভিগেশন প্রদানের জন্য AndroidX Activity API ব্যবহার করার পরামর্শ দিই। যদি সিস্টেম ব্যাক প্রেসকে আটকানোর জন্য কোনও উপাদান না থাকে তবে AndroidX Activity API স্বয়ংক্রিয়ভাবে উপযুক্ত সিস্টেম আচরণের উপর নির্ভর করে।
গ্রাফিক্স এবং ছবি
উন্নত রিফ্রেশ রেট স্যুইচিং
অ্যান্ড্রয়েড ১২-তে, setFrameRate() ব্যবহার করে রিফ্রেশ রেট পরিবর্তন ঘটতে পারে, ডিসপ্লেটি নতুন রিফ্রেশ রেটে নিরবচ্ছিন্ন রূপান্তর সমর্থন করে কিনা তা নির্বিশেষে; একটি নিরবচ্ছিন্ন রূপান্তর হল এমন একটি রূপান্তর যার কোনও ভিজ্যুয়াল বাধা নেই, যেমন এক বা দুই সেকেন্ডের জন্য কালো পর্দা। পূর্বে, যদি ডিসপ্লেটি নিরবচ্ছিন্ন রূপান্তর সমর্থন না করত, setFrameRate() কল করার পরে এটি সাধারণত একই রিফ্রেশ রেট ব্যবহার চালিয়ে যেত। আপনি getAlternativeRefreshRates() কল করে নতুন রিফ্রেশে রূপান্তর সম্ভবত নিরবচ্ছিন্ন হবে কিনা তা আগে থেকেই নির্ধারণ করতে পারেন। সাধারণত, রিফ্রেশ রেট সুইচ সম্পূর্ণ হওয়ার পরে onDisplayChanged() কল করা হয়, তবে কিছু বাহ্যিকভাবে সংযুক্ত ডিসপ্লের জন্য, এটি একটি নন-সিমলেস রূপান্তরের সময় কল করা হয়।
আপনি এটি কীভাবে বাস্তবায়ন করতে পারেন তার একটি উদাহরণ এখানে দেওয়া হল:
কোটলিন
// 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);
সংযোগ
পাসপয়েন্ট আপডেট
অ্যান্ড্রয়েড ১২-তে নিম্নলিখিত API গুলি যোগ করা হয়েছে:
-
isPasspointTermsAndConditionsSupported(): শর্তাবলী হল একটি পাসপয়েন্ট বৈশিষ্ট্য যা নেটওয়ার্ক স্থাপনাগুলিকে অনিরাপদ ক্যাপটিভ পোর্টালগুলিকে প্রতিস্থাপন করতে দেয়, যা ওপেন নেটওয়ার্ক ব্যবহার করে, একটি নিরাপদ পাসপয়েন্ট নেটওয়ার্ক দিয়ে। শর্তাবলী গ্রহণের প্রয়োজন হলে ব্যবহারকারীকে একটি বিজ্ঞপ্তি প্রদর্শিত হয়। যেসব অ্যাপ শর্তাবলী দ্বারা গেটেড পাসপয়েন্ট নেটওয়ার্কের পরামর্শ দেয়, তাদের অবশ্যই প্রথমে এই API কল করতে হবে যাতে নিশ্চিত করা যায় যে ডিভাইসটি ক্ষমতা সমর্থন করে। যদি ডিভাইসটি ক্ষমতা সমর্থন না করে, তাহলে এটি এই নেটওয়ার্কের সাথে সংযোগ করতে সক্ষম হবে না এবং একটি বিকল্প বা লিগ্যাসি নেটওয়ার্ক প্রস্তাব করতে হবে। isDecoratedIdentitySupported(): যখন একটি প্রিফিক্স ডেকোরেশন সহ নেটওয়ার্কগুলিতে প্রমাণীকরণ করা হয়, তখন সজ্জিত পরিচয় প্রিফিক্স নেটওয়ার্ক অপারেটরদের AAA নেটওয়ার্কের ভিতরে একাধিক প্রক্সির মাধ্যমে স্পষ্ট রাউটিং সম্পাদনের জন্য নেটওয়ার্ক অ্যাক্সেস আইডেন্টিফায়ার (NAI) আপডেট করার অনুমতি দেয় (এ সম্পর্কে আরও জানতে RFC 7542 দেখুন)।Android 12 PPS-MO এক্সটেনশনের জন্য WBA স্পেসিফিকেশনের সাথে সঙ্গতিপূর্ণ হওয়ার জন্য এই বৈশিষ্ট্যটি প্রয়োগ করে। যেসব অ্যাপ পাসপয়েন্ট নেটওয়ার্কের জন্য একটি সজ্জিত পরিচয়ের প্রয়োজন হয় তাদের প্রথমে এই API কল করতে হবে যাতে নিশ্চিত করা যায় যে ডিভাইসটি ক্ষমতা সমর্থন করে। যদি ডিভাইসটি ক্ষমতা সমর্থন না করে, তাহলে পরিচয়টি সজ্জিত হবে না এবং নেটওয়ার্কের প্রমাণীকরণ ব্যর্থ হতে পারে।
পাসপয়েন্ট সাজেশন তৈরি করতে, অ্যাপগুলিকে PasspointConfiguration , Credential এবং HomeSp ক্লাস ব্যবহার করতে হবে। এই ক্লাসগুলি পাসপয়েন্ট প্রোফাইল বর্ণনা করে, যা ওয়াই-ফাই অ্যালায়েন্স পাসপয়েন্ট স্পেসিফিকেশনে সংজ্ঞায়িত করা হয়েছে।
আরও তথ্যের জন্য, ইন্টারনেট সংযোগের জন্য Wi-Fi সাজেশন API দেখুন।
আপডেট করা নন-SDK ইন্টারফেস সীমাবদ্ধতা
অ্যান্ড্রয়েড ১২-তে অ্যান্ড্রয়েড ডেভেলপারদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। যখনই সম্ভব, আমরা নিশ্চিত করি যে নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে।
যদি আপনার অ্যাপটি Android 12-কে টার্গেট না করে, তাহলে এই পরিবর্তনগুলির কিছু তাৎক্ষণিকভাবে আপনার উপর প্রভাব ফেলতে পারে না। তবে, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API স্তরের উপর নির্ভর করে ), যেকোনো নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে আপনার অ্যাপটি ভেঙে যাওয়ার ঝুঁকি সবসময় বেশি থাকে।
যদি আপনার অ্যাপটি নন-SDK ইন্টারফেস ব্যবহার করে কিনা তা নিশ্চিত না হন, তাহলে আপনি আপনার অ্যাপটি পরীক্ষা করে দেখতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে মাইগ্রেশনের পরিকল্পনা শুরু করা উচিত। তবুও, আমরা বুঝতে পারি যে কিছু অ্যাপের নন-SDK ইন্টারফেস ব্যবহারের জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। যদি আপনি আপনার অ্যাপে কোনও বৈশিষ্ট্যের জন্য নন-SDK ইন্টারফেস ব্যবহারের বিকল্প খুঁজে না পান, তাহলে আপনার একটি নতুন পাবলিক API অনুরোধ করা উচিত।
অ্যান্ড্রয়েডের এই রিলিজে পরিবর্তনগুলি সম্পর্কে আরও জানতে, অ্যান্ড্রয়েড ১২-তে নন-এসডিকে ইন্টারফেস সীমাবদ্ধতার আপডেটগুলি দেখুন। সাধারণত নন-এসডিকে ইন্টারফেস সম্পর্কে আরও জানতে, নন-এসডিকে ইন্টারফেসের উপর বিধিনিষেধগুলি দেখুন।