অ্যান্ড্রয়েড ১২ প্ল্যাটফর্মে এমন কিছু আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। targetSdkVersion নির্বিশেষে, অ্যান্ড্রয়েড ১২-এ চালিত সমস্ত অ্যাপের ক্ষেত্রে নিম্নলিখিত আচরণগত পরিবর্তনগুলি প্রযোজ্য। আপনার অ্যাপটি পরীক্ষা করে দেখা উচিত এবং তারপরে যেখানে প্রযোজ্য, এই পরিবর্তনগুলিকে সঠিকভাবে সমর্থন করার জন্য প্রয়োজন অনুযায়ী এটিতে পরিবর্তন আনা উচিত।
অ্যান্ড্রয়েড ১২ টার্গেট করা অ্যাপগুলোর জন্য প্রযোজ্য আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করে নিতে ভুলবেন না।
ব্যবহারকারীর অভিজ্ঞতা
স্ট্রেচ ওভারস্ক্রোল প্রভাব
অ্যান্ড্রয়েড ১২ এবং এর পরবর্তী সংস্করণ চালিত ডিভাইসগুলোতে ওভারস্ক্রোল ইভেন্টের ভিজ্যুয়াল আচরণ পরিবর্তিত হয়।
অ্যান্ড্রয়েড ১১ এবং এর নিচের সংস্করণগুলোতে, ওভারস্ক্রোল ইভেন্টের ফলে ভিজ্যুয়াল এলিমেন্টগুলোতে একটি আভা দেখা যায়; অ্যান্ড্রয়েড ১২ এবং এর উপরের সংস্করণগুলোতে, ড্র্যাগ ইভেন্টে ভিজ্যুয়াল এলিমেন্টগুলো প্রসারিত হয়ে আগের অবস্থায় ফিরে আসে এবং ফ্লিং ইভেন্টে সেগুলো ছিটকে গিয়ে আবার আগের অবস্থায় ফিরে আসে।
আরও তথ্যের জন্য, স্ক্রোল জেসচার অ্যানিমেট করার নির্দেশিকাটি দেখুন।
অ্যাপ স্প্ল্যাশ স্ক্রিন
আপনি যদি আগে অ্যান্ড্রয়েড ১১ বা তার নিচের সংস্করণে কোনো কাস্টম স্প্ল্যাশ স্ক্রিন প্রয়োগ করে থাকেন, তাহলে অ্যান্ড্রয়েড ১২ থেকে এটি সঠিকভাবে প্রদর্শিত হওয়া নিশ্চিত করতে আপনাকে আপনার অ্যাপটিকে SplashScreen এপিআই-তে মাইগ্রেট করতে হবে। আপনার অ্যাপটি মাইগ্রেট না করলে, অ্যাপটি চালু করার অভিজ্ঞতা নিম্নমানের বা অনাকাঙ্ক্ষিত হবে।
নির্দেশাবলীর জন্য, আপনার বিদ্যমান স্প্ল্যাশ স্ক্রিন বাস্তবায়নকে অ্যান্ড্রয়েড ১২-এ মাইগ্রেট করুন দেখুন।
এছাড়াও, অ্যান্ড্রয়েড ১২ থেকে শুরু করে, সিস্টেমটি সমস্ত অ্যাপের কোল্ড এবং ওয়ার্ম স্টার্টের সময় সর্বদা নতুন অ্যান্ড্রয়েড সিস্টেমের ডিফল্ট স্প্ল্যাশ স্ক্রিনটি প্রয়োগ করে। ডিফল্টরূপে, এই সিস্টেমের ডিফল্ট স্প্ল্যাশ স্ক্রিনটি আপনার অ্যাপের লঞ্চার আইকন এলিমেন্ট এবং আপনার থিমের windowBackground (যদি এটি একরঙা হয়) ব্যবহার করে তৈরি করা হয়।
আরও বিস্তারিত জানতে, স্প্ল্যাশ স্ক্রিন ডেভেলপার গাইডটি দেখুন।
ওয়েব অভিপ্রায় সমাধান
অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) থেকে, একটি জেনেরিক ওয়েব ইন্টেন্ট আপনার অ্যাপের কোনো অ্যাক্টিভিটিতে তখনই রিজলভ হয়, যখন আপনার অ্যাপটি সেই ওয়েব ইন্টেন্টে থাকা নির্দিষ্ট ডোমেইনের জন্য অনুমোদিত থাকে। যদি আপনার অ্যাপটি ডোমেইনটির জন্য অনুমোদিত না হয়, তবে ওয়েব ইন্টেন্টটি এর পরিবর্তে ব্যবহারকারীর ডিফল্ট ব্রাউজার অ্যাপে রিজলভ হয়।
অ্যাপগুলো নিম্নলিখিত উপায়গুলোর যেকোনো একটি অনুসরণ করে এই অনুমোদন পেতে পারে:
অ্যান্ড্রয়েড অ্যাপ লিঙ্ক ব্যবহার করে ডোমেইনটি যাচাই করুন।
যেসব অ্যাপ অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি, সেগুলোতে সিস্টেম আপনার অ্যাপের অ্যান্ড্রয়েড অ্যাপ লিঙ্কগুলো স্বয়ংক্রিয়ভাবে যাচাই করার পদ্ধতি পরিবর্তন করে। আপনার অ্যাপের ইন্টেন্ট ফিল্টারগুলোতে , নিশ্চিত করুন যে আপনি
BROWSABLEক্যাটাগরিটি অন্তর্ভুক্ত করেছেন এবংhttpsস্কিমটি সমর্থন করেন।অ্যান্ড্রয়েড ১২ বা তার পরবর্তী সংস্করণে, এই আপডেট করা লজিকটি আপনার অ্যাপকে কীভাবে প্রভাবিত করে তা পরীক্ষা করার জন্য, আপনি ম্যানুয়ালি আপনার অ্যাপের অ্যান্ড্রয়েড অ্যাপ লিঙ্কগুলি যাচাই করতে পারেন।
সিস্টেম সেটিংসে আপনার অ্যাপটিকে ডোমেইনের সাথে যুক্ত করতে ব্যবহারকারীকে অনুরোধ করুন ।
আপনার অ্যাপ যদি ওয়েব ইন্টেন্ট ব্যবহার করে, তবে ব্যবহারকারীকে কাজটি নিশ্চিত করতে বলার জন্য একটি প্রম্পট বা ডায়ালগ যোগ করার কথা বিবেচনা করতে পারেন।
জেসচার নেভিগেশনের জন্য ইমারসিভ মোডের উন্নতি
অ্যান্ড্রয়েড ১২ বিদ্যমান আচরণকে আরও সুসংহত করেছে, যাতে ব্যবহারকারীরা ইমার্সিভ মোডে থাকাকালীন জেসচার নেভিগেশন কমান্ডগুলো আরও সহজে সম্পাদন করতে পারেন। এছাড়াও, অ্যান্ড্রয়েড ১২ স্টিকি ইমার্সিভ মোডের জন্য ব্যাকওয়ার্ড কম্প্যাটিবিলিটি আচরণ প্রদান করে।
Display#getRealSize এবং getRealMetrics: অপ্রচলিতকরণ এবং সীমাবদ্ধতা
অ্যান্ড্রয়েড ডিভাইসগুলো বিভিন্ন ফর্ম ফ্যাক্টরে পাওয়া যায়, যেমন বড় স্ক্রিন, ট্যাবলেট এবং ফোল্ডেবল। প্রতিটি ডিভাইসের জন্য কন্টেন্ট যথাযথভাবে রেন্ডার করতে, আপনার অ্যাপকে স্ক্রিন বা ডিসপ্লের আকার নির্ধারণ করতে হয়। সময়ের সাথে সাথে, অ্যান্ড্রয়েড এই তথ্য সংগ্রহের জন্য বিভিন্ন এপিআই (API) প্রদান করেছে। অ্যান্ড্রয়েড ১১-এ, আমরা WindowMetrics এপিআই চালু করেছি এবং এই মেথডগুলোকে ডেপ্রিকেটেড (deprecated) করেছি:
অ্যান্ড্রয়েড ১২-এ আমরা WindowMetrics ব্যবহার করার সুপারিশ অব্যাহত রাখছি এবং এই মেথডগুলোকে অপ্রচলিত ঘোষণা করছি:
অ্যাপ্লিকেশনের সীমানা (bounds) পাওয়ার জন্য ডিসপ্লে এপিআই (Display APIs) ব্যবহারকারী অ্যাপ্লিকেশনগুলির আচরণ প্রশমিত করতে, অ্যান্ড্রয়েড ১২ সেইসব অ্যাপের জন্য এপিআই দ্বারা ফেরত আসা মানগুলিকে সীমাবদ্ধ করে যেগুলি সম্পূর্ণরূপে রিসাইজযোগ্য নয়। এটি সেইসব অ্যাপের উপর প্রভাব ফেলতে পারে যেগুলি MediaProjection এর সাথে এই তথ্য ব্যবহার করছে।
অ্যাপগুলোর উচিত তাদের উইন্ডোর সীমানা জানতে WindowMetrics API এবং বর্তমান ঘনত্ব জানতে Configuration.densityDpi ব্যবহার করা।
অ্যান্ড্রয়েডের পুরোনো সংস্করণগুলোর সাথে আরও ভালো সামঞ্জস্যের জন্য, আপনি Jetpack WindowManager লাইব্রেরিটি ব্যবহার করতে পারেন, যেটিতে একটি WindowMetrics ক্লাস রয়েছে যা অ্যান্ড্রয়েড ৪.০ (এপিআই লেভেল ১৪) এবং তার পরবর্তী সংস্করণগুলোকে সমর্থন করে।
WindowMetrics ব্যবহারের উদাহরণ
প্রথমত, নিশ্চিত করুন যে আপনার অ্যাপের অ্যাক্টিভিটিগুলো সম্পূর্ণরূপে রিসাইজযোগ্য ।
যেকোনো UI-সম্পর্কিত কাজের জন্য একটি অ্যাক্টিভিটির অ্যাক্টিভিটি কনটেক্সট থেকে WindowMetrics উপর নির্ভর করা উচিত, বিশেষ করে WindowManager.getCurrentWindowMetrics() অথবা Jetpack-এর WindowMetricsCalculator.computeCurrentWindowMetrics() উপর।
যদি আপনার অ্যাপ একটি 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 ) থাকে, সেগুলোতে ক্যামেরা সেন্সরের ওরিয়েন্টেশনের সাথে সামঞ্জস্য রাখতে ক্যামেরা আউটপুটে অতিরিক্ত রোটেশন প্রয়োগ করা হয় এবং অ্যাপের ক্যামেরা প্রিভিউয়ের অ্যাস্পেক্ট রেশিওর সাথে মেলানোর জন্য ক্যামেরা আউটপুটটি ক্রপ করা হয়। এই ক্রপিং এবং অতিরিক্ত রোটেশন ডিভাইসের ওরিয়েন্টেশন এবং ডিভাইসটি ভাঁজ করা বা খোলা অবস্থা নির্বিশেষে ক্যামেরা প্রিভিউয়ের সঠিক উপস্থাপনা নিশ্চিত করে।
ফোরগ্রাউন্ড সার্ভিস নোটিফিকেশনের জন্য ইউএক্স বিলম্ব
স্বল্পস্থায়ী ফোরগ্রাউন্ড সার্ভিসগুলোর জন্য একটি সুবিন্যস্ত অভিজ্ঞতা প্রদানের লক্ষ্যে, অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণে চালিত ডিভাইসগুলো কয়েকটি ব্যতিক্রম ছাড়া ফোরগ্রাউন্ড সার্ভিসের নোটিফিকেশন প্রদর্শনে ১০ সেকেন্ড পর্যন্ত বিলম্ব করতে পারে। এই পরিবর্তনটি স্বল্পস্থায়ী টাস্কগুলোকে তাদের নোটিফিকেশন প্রদর্শিত হওয়ার আগে সম্পূর্ণ হওয়ার সুযোগ দেয়।
কর্মক্ষমতা
সীমাবদ্ধ অ্যাপ স্ট্যান্ডবাই বালতি
অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০)-এ অ্যাপ স্ট্যান্ডবাই বাকেট হিসেবে রেস্ট্রিকটেড বাকেট চালু করা হয়েছিল। অ্যান্ড্রয়েড ১২ থেকে এই বাকেটটি ডিফল্টরূপে সক্রিয় থাকে। সমস্ত বাকেটের মধ্যে রেস্ট্রিকটেড বাকেটের প্রায়োরিটি সবচেয়ে কম (এবং বিধিনিষেধ সবচেয়ে বেশি)। প্রায়োরিটি অনুসারে উচ্চ থেকে নিম্ন ক্রমে বাকেটগুলো হলো:
- সক্রিয়: অ্যাপটি বর্তমানে ব্যবহৃত হচ্ছে অথবা খুব সম্প্রতি ব্যবহৃত হয়েছে।
- কার্যপরিবেশ: অ্যাপটি নিয়মিত ব্যবহার করা হচ্ছে।
- ঘন ঘন: অ্যাপটি প্রায়ই ব্যবহার করা হয়, কিন্তু প্রতিদিন নয়।
- বিরল: অ্যাপটি ঘন ঘন ব্যবহার করা হয় না।
- সীমাবদ্ধ: অ্যাপটি প্রচুর পরিমাণে সিস্টেম রিসোর্স ব্যবহার করে, অথবা অনাকাঙ্ক্ষিত আচরণ প্রদর্শন করতে পারে।
আপনার অ্যাপটিকে সীমাবদ্ধ তালিকায় রাখা হবে কিনা, সেই সিদ্ধান্ত নেওয়ার জন্য সিস্টেমটি ব্যবহারের ধরনের পাশাপাশি আপনার অ্যাপের আচরণও বিবেচনা করে।
আপনার অ্যাপ যদি সিস্টেম রিসোর্স আরও দায়িত্বশীলভাবে ব্যবহার করে, তাহলে সেটিকে সীমাবদ্ধ তালিকায় রাখার সম্ভাবনা কম থাকে। এছাড়াও, ব্যবহারকারী যদি সরাসরি আপনার অ্যাপের সাথে ইন্টারঅ্যাক্ট করে, তাহলে সিস্টেম আপনার অ্যাপটিকে একটি কম সীমাবদ্ধ তালিকায় রাখে।
আপনার অ্যাপটি সীমাবদ্ধ তালিকায় আছে কিনা তা যাচাই করুন।
সিস্টেম আপনার অ্যাপটিকে সীমাবদ্ধ বাকেটে রেখেছে কিনা তা পরীক্ষা করতে, getAppStandbyBucket() কল করুন। যদি এই মেথডের রিটার্ন ভ্যালু STANDBY_BUCKET_RESTRICTED হয়, তাহলে আপনার অ্যাপটি সীমাবদ্ধ বাকেটে রয়েছে।
সীমাবদ্ধ বালতির আচরণ পরীক্ষা করুন
সিস্টেম যখন আপনার অ্যাপটিকে সীমাবদ্ধ বাকেটে রাখে, তখন এটি কীভাবে আচরণ করে তা পরীক্ষা করার জন্য, আপনি ম্যানুয়ালি আপনার অ্যাপটিকে সেই বাকেটে সরাতে পারেন। এটি করার জন্য, একটি টার্মিনাল উইন্ডোতে নিম্নলিখিত কমান্ডটি চালান:
adb shell am set-standby-bucket PACKAGE_NAME restricted
ফোরগ্রাউন্ড অবস্থান এবং ব্যাটারি সেভার
অ্যান্ড্রয়েড ১২ থেকে শুরু করে, ব্যাটারি সেভার সক্রিয় থাকা অবস্থায়, এমনকি স্ক্রিন বন্ধ থাকলেও ফোরগ্রাউন্ড লোকেশন (ফোরগ্রাউন্ড সার্ভিস থেকেও) পাঠানো অব্যাহত থাকতে পারে।
পূর্বে, স্ক্রিন বন্ধ থাকলে ব্যাটারি সেভার মোড লোকেশন আপডেট বন্ধ করে দিত। এই পরিবর্তনটি ব্যবহারকারীদের জন্য আরও ভালো ব্যাটারি লাইফ নিশ্চিত করে এবং এর ফলে ডেভেলপাররা লোকেশন ডেলিভারি নিশ্চিত করার জন্য ব্যবহারকারীদের ব্যাটারি সেভার নিষ্ক্রিয় করতে বলার থেকে বিরত থাকতে পারবেন।
যেসব অ্যাপ ফোরগ্রাউন্ড সার্ভিসের মাধ্যমে অবস্থানের জন্য অনুরোধ করে, তাদের নিম্নলিখিত পদক্ষেপগুলো গ্রহণ করা উচিত:
- ব্যাটারি সেভার সক্রিয় থাকাকালীন ডিভাইসের লোকেশন ফিচারগুলো কীভাবে কাজ করে তা জানতে
getLocationPowerSaverMode()কল করুন। - যদি এটি
LOCATION_MODE_FOREGROUND_ONLYরিটার্ন করে, তাহলে ব্যাটারি সেভার চালু এবং স্ক্রিন বন্ধ থাকা অবস্থায়ও আপনার অ্যাপটি ফোরগ্রাউন্ডে থাকলে বা কোনো ফোরগ্রাউন্ড সার্ভিস চালালে লোকেশন আপডেট পেতে থাকবে।
নিরাপত্তা এবং গোপনীয়তা
আনুমানিক অবস্থান
অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণে চালিত ডিভাইসগুলিতে, ব্যবহারকারীরা আপনার অ্যাপকে শুধুমাত্র আনুমানিক অবস্থানের তথ্য অ্যাক্সেস করার জন্য অনুরোধ করতে পারেন।
যদি আপনার অ্যাপ ACCESS_FINE_LOCATION রানটাইম পারমিশনটি অনুরোধ করে, তবে ব্যবহারকারী আপনার অ্যাপকে আনুমানিক অবস্থানের অ্যাক্সেস দিলে সেই পরিস্থিতি সামাল দেওয়ার জন্য আপনার ACCESS_COARSE_LOCATION পারমিশনটিও অনুরোধ করা উচিত। আপনার উভয় পারমিশন একটিমাত্র রানটাইম অনুরোধের মধ্যেই অন্তর্ভুক্ত করা উচিত।
সিস্টেম পারমিশন ডায়ালগে ব্যবহারকারীর জন্য নিম্নলিখিত অপশনগুলো অন্তর্ভুক্ত থাকে, যেমনটি চিত্র ১-এ দেখানো হয়েছে:
- সুনির্দিষ্ট : সুনির্দিষ্ট অবস্থানের তথ্য পাওয়ার সুযোগ দেয়।
- আনুমানিক : শুধুমাত্র আনুমানিক অবস্থানের তথ্য দেখার সুযোগ দেয়।
মাইক্রোফোন এবং ক্যামেরা টগল
অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণে চালিত সমর্থিত ডিভাইসগুলোতে, ব্যবহারকারীরা একটিমাত্র টগল অপশন চাপার মাধ্যমে ডিভাইসের সমস্ত অ্যাপের জন্য ক্যামেরা এবং মাইক্রোফোন অ্যাক্সেস চালু ও বন্ধ করতে পারেন। ব্যবহারকারীরা চিত্র ১-এ দেখানো অনুযায়ী কুইক সেটিংস থেকে, অথবা সিস্টেম সেটিংসের প্রাইভেসি স্ক্রিন থেকে এই টগলযোগ্য অপশনগুলো অ্যাক্সেস করতে পারেন।
এই টগলগুলো সম্পর্কে আরও জানুন, এবং আপনার অ্যাপটি CAMERA ও RECORD_AUDIO পারমিশন সংক্রান্ত সর্বোত্তম অনুশীলনগুলো অনুসরণ করছে কিনা তা কীভাবে পরীক্ষা করবেন তা জেনে নিন।
মাইক্রোফোন এবং ক্যামেরা সূচক
অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণে চালিত ডিভাইসগুলিতে, যখন কোনো অ্যাপ মাইক্রোফোন বা ক্যামেরা ব্যবহার করে, তখন স্ট্যাটাস বারে একটি আইকন দেখা যায়।
এই সূচকগুলো সম্পর্কে আরও জানুন এবং আপনার অ্যাপটি CAMERA ও RECORD_AUDIO পারমিশন সংক্রান্ত সর্বোত্তম অনুশীলনগুলো অনুসরণ করছে কিনা, তা কীভাবে পরীক্ষা করবেন তা শিখুন।
অনুমতি প্যাকেজের দৃশ্যমানতা
যেসব ডিভাইসে অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণ চলে, সেগুলোতে যে অ্যাপগুলো অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) বা তার উচ্চতর সংস্করণকে টার্গেট করে এবং নিম্নলিখিত পদ্ধতিগুলোর মধ্যে কোনো একটিকে কল করে, সেগুলো অন্যান্য অ্যাপে অ্যাপটির প্যাকেজ ভিজিবিলিটির উপর ভিত্তি করে একটি ফিল্টার করা ফলাফল সেট পায়:
বাউন্সি ক্যাসেল বাস্তবায়ন সরানো হয়েছে
অ্যান্ড্রয়েড ১২ পূর্বে বাতিল ঘোষিত হওয়া অনেক ক্রিপ্টোগ্রাফিক অ্যালগরিদমের BouncyCastle ইমপ্লিমেন্টেশন সরিয়ে দিয়েছে, যার মধ্যে সমস্ত AES অ্যালগরিদম অন্তর্ভুক্ত। এর পরিবর্তে সিস্টেমটি এই অ্যালগরিদমগুলোর Conscrypt ইমপ্লিমেন্টেশন ব্যবহার করে।
নিম্নলিখিতগুলির মধ্যে কোনোটি সত্য হলে এই পরিবর্তনটি আপনার অ্যাপকে প্রভাবিত করবে:
- আপনার অ্যাপটি ৫১২-বিট কী সাইজ ব্যবহার করে। কনস্ক্রিপ্ট এই কী সাইজটি সমর্থন করে না। প্রয়োজনে, ভিন্ন কী সাইজ ব্যবহার করার জন্য আপনার অ্যাপের ক্রিপ্টোগ্রাফি লজিক আপডেট করুন।
আপনার অ্যাপ
KeyGeneratorসাথে অবৈধ কী সাইজ ব্যবহার করছে। BouncyCastle-এর তুলনায় Conscrypt-এরKeyGeneratorইমপ্লিমেন্টেশনটি কী প্যারামিটারগুলোর উপর অতিরিক্ত ভ্যালিডেশন করে থাকে। উদাহরণস্বরূপ, Conscrypt আপনার অ্যাপকে একটি ৬৪-বিট AES কী তৈরি করতে দেয় না, কারণ AES শুধুমাত্র ১২৮-, ১৯২-, এবং ২৫৬-বিট কী সাপোর্ট করে।BouncyCastle অবৈধ আকারের কী তৈরি করার অনুমতি দেয়, কিন্তু পরে এই কীগুলি কোনো
Cipherসাথে ব্যবহার করা হলে ব্যর্থ হয়। Conscrypt আরও আগে ব্যর্থ হয়।আপনি আপনার গ্যালয়/কাউন্টার মোড (GCM) সাইফারগুলো ১২ বাইট ছাড়া অন্য কোনো সাইজ ব্যবহার করে ইনিশিয়ালাইজ করেন। Conscrypt-এর
GcmParameterSpecইমপ্লিমেন্টেশনের জন্য ১২ বাইটের একটি ইনিশিয়ালাইজেশন প্রয়োজন, যা NIST সুপারিশ করে।
ক্লিপবোর্ড অ্যাক্সেস বিজ্ঞপ্তি
অ্যান্ড্রয়েড ১২ এবং এর পরবর্তী সংস্করণগুলোতে, যখন কোনো অ্যাপ প্রথমবারের মতো অন্য কোনো অ্যাপ থেকে ক্লিপ ডেটা অ্যাক্সেস করার জন্য getPrimaryClip() কল করে, তখন একটি টোস্ট মেসেজের মাধ্যমে ব্যবহারকারীকে এই ক্লিপবোর্ড অ্যাক্সেসের বিষয়ে অবহিত করা হয়।
টোস্ট মেসেজের ভেতরের টেক্সটটিতে নিম্নলিখিত ফরম্যাট থাকে: APP pasted from your clipboard.
ক্লিপ বিবরণে পাঠ্য সম্পর্কে তথ্য
অ্যান্ড্রয়েড ১২ এবং তার পরবর্তী সংস্করণগুলোতে, getPrimaryClipDescription() নিম্নলিখিত বিবরণগুলো শনাক্ত করতে পারে:
-
isStyledText()ব্যবহার করে টেক্সটকে শৈলীমণ্ডিত করা হয়েছে। -
getConfidenceScore()ব্যবহার করে টেক্সটের বিভিন্ন শ্রেণিবিভাগ, যেমন URL।
অ্যাপগুলি সিস্টেম ডায়ালগ বন্ধ করতে পারে না
অ্যাপ এবং সিস্টেমের সাথে ইন্টারঅ্যাক্ট করার সময় ব্যবহারকারীর নিয়ন্ত্রণ উন্নত করার জন্য, অ্যান্ড্রয়েড ১২ থেকে ACTION_CLOSE_SYSTEM_DIALOGS ইন্টেন্ট অ্যাকশনটি বাতিল করা হয়েছে। কয়েকটি বিশেষ ক্ষেত্র ছাড়া, যখন আপনার অ্যাপ এই অ্যাকশনটি ধারণকারী কোনো ইন্টেন্ট চালু করার চেষ্টা করে, তখন আপনার অ্যাপের টার্গেট SDK ভার্সনের উপর ভিত্তি করে সিস্টেম নিম্নলিখিত কাজগুলোর মধ্যে একটি করে থাকে:
- আপনার অ্যাপটি অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণকে টার্গেট করলে একটি
SecurityExceptionদেখা দেয়। আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) বা তার নিচের সংস্করণকে টার্গেট করে, তাহলে ইন্টেন্টটি এক্সিকিউট হয় না এবং লগক্যাটে নিম্নলিখিত মেসেজটি দেখা যায়:
E ActivityTaskManager Permission Denial: \ android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \ com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \ dropping broadcast.
ব্যতিক্রম
নিম্নলিখিত ক্ষেত্রে, একটি অ্যাপ এখনও অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণে সিস্টেম ডায়ালগ বন্ধ করতে পারে:
- আপনার অ্যাপটি একটি ইন্সট্রুমেন্টেশন টেস্ট চালাচ্ছে।
আপনার অ্যাপটি অ্যান্ড্রয়েড ১১ বা তার নিম্নতর সংস্করণকে লক্ষ্য করে তৈরি এবং এটি নোটিফিকেশন ড্রয়ারের উপরে একটি উইন্ডো দেখাচ্ছে।
আপনার অ্যাপটি অ্যান্ড্রয়েড ১১ বা তার নিম্নতর সংস্করণকে লক্ষ্য করে তৈরি। এছাড়াও, ব্যবহারকারী একটি নোটিফিকেশনের সাথে ইন্টারঅ্যাক্ট করেছেন, সম্ভবত নোটিফিকেশনটির অ্যাকশন বাটনগুলো ব্যবহার করে, এবং ব্যবহারকারীর সেই কার্যকলাপের প্রতিক্রিয়ায় আপনার অ্যাপটি একটি সার্ভিস বা ব্রডকাস্ট রিসিভার প্রসেস করছে।
আপনার অ্যাপটি অ্যান্ড্রয়েড ১১ বা তার নিচের সংস্করণকে লক্ষ্য করে তৈরি এবং এতে একটি সক্রিয় অ্যাক্সেসিবিলিটি পরিষেবা রয়েছে। যদি আপনার অ্যাপটি অ্যান্ড্রয়েড ১২-কে লক্ষ্য করে তৈরি হয় এবং নোটিফিকেশন বার বন্ধ করতে চায়, তাহলে এর পরিবর্তে
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADEঅ্যাক্সেসিবিলিটি অ্যাকশনটি ব্যবহার করুন।
অবিশ্বস্ত টাচ ইভেন্টগুলি ব্লক করা হয়েছে
সিস্টেমের নিরাপত্তা এবং ব্যবহারকারীর ভালো অভিজ্ঞতা বজায় রাখার জন্য, অ্যান্ড্রয়েড ১২ এমন অ্যাপগুলোকে টাচ ইভেন্ট গ্রহণ করতে বাধা দেয়, যেখানে কোনো ওভারলে অনিরাপদভাবে অ্যাপটিকে আড়াল করে রাখে। অন্য কথায়, সিস্টেমটি কিছু ব্যতিক্রম ছাড়া, নির্দিষ্ট কিছু উইন্ডোর মধ্য দিয়ে যাওয়া টাচগুলোকে ব্লক করে দেয়।
প্রভাবিত অ্যাপগুলি
এই পরিবর্তনটি সেইসব অ্যাপকে প্রভাবিত করে, যারা FLAG_NOT_TOUCHABLE ফ্ল্যাগ ব্যবহারের মাধ্যমে তাদের উইন্ডোর মধ্য দিয়ে টাচকে যেতে দেয়। এর কয়েকটি উদাহরণ নিচে দেওয়া হলো, তবে এগুলোই একমাত্র উদাহরণ নয়:
- যেসব ওভারলে-র জন্য
SYSTEM_ALERT_WINDOWপারমিশন প্রয়োজন, যেমনTYPE_APPLICATION_OVERLAYব্যবহারকারী উইন্ডোগুলো, সেগুলোFLAG_NOT_TOUCHABLEফ্ল্যাগ ব্যবহার করে। - অ্যাক্টিভিটি উইন্ডোগুলো
FLAG_NOT_TOUCHABLEফ্ল্যাগ ব্যবহার করে।
ব্যতিক্রম
নিম্নলিখিত ক্ষেত্রে, 'পাস-থ্রু' টাচ অনুমোদিত:
- আপনার অ্যাপের মধ্যেকার মিথস্ক্রিয়া। আপনার অ্যাপটি ওভারলেটি দেখায়, এবং ওভারলেটি শুধুমাত্র তখনই প্রদর্শিত হয় যখন ব্যবহারকারী আপনার অ্যাপের সাথে মিথস্ক্রিয়া করেন।
নির্ভরযোগ্য জানালা। এই জানালাগুলোর মধ্যে নিম্নলিখিতগুলো অন্তর্ভুক্ত (তবে এগুলোতেই সীমাবদ্ধ নয়):
অদৃশ্য উইন্ডো। উইন্ডোটির রুট ভিউটি
GONEবাINVISIBLEহয়ে গেছে।সম্পূর্ণ স্বচ্ছ জানালা। জানালাটির
alphaপ্রপার্টির মান ০.০।পর্যাপ্ত স্বচ্ছ সিস্টেম অ্যালার্ট উইন্ডো। সিস্টেম অ্যালার্ট উইন্ডোগুলোর একটি সেটকে তখনই পর্যাপ্ত স্বচ্ছ বলে মনে করে, যখন সেগুলোর সম্মিলিত অস্বচ্ছতা টাচের জন্য সিস্টেমের সর্বোচ্চ প্রতিবন্ধক অপাসিটির সমান বা তার চেয়ে কম হয়। অ্যান্ড্রয়েড ১২-এ, এই সর্বোচ্চ অস্বচ্ছতা ডিফল্টভাবে ০.৮।
কখন একটি অবিশ্বস্ত স্পর্শ ব্লক করা হয়েছে তা সনাক্ত করুন
যদি সিস্টেম দ্বারা কোনো টাচ অ্যাকশন ব্লক করা হয়, তাহলে Logcat নিম্নলিখিত বার্তাটি লগ করে:
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
কার্যকলাপের জীবনচক্র
ব্যাক প্রেস করলে রুট লঞ্চারের কার্যকলাপ আর শেষ হয় না।
অ্যান্ড্রয়েড ১২ লঞ্চার অ্যাক্টিভিটিগুলোর রুটে থাকা অবস্থায় সিস্টেমের ব্যাক প্রেসের ডিফল্ট হ্যান্ডলিং পরিবর্তন করেছে। পূর্ববর্তী সংস্করণগুলোতে, ব্যাক প্রেস করলে সিস্টেম এই অ্যাক্টিভিটিগুলো শেষ করে দিত। অ্যান্ড্রয়েড ১২-এ, সিস্টেম এখন অ্যাক্টিভিটিটি শেষ না করে সেটিকে এবং তার কাজটিকে ব্যাকগ্রাউন্ডে পাঠিয়ে দেয়। এই নতুন আচরণটি হোম বাটন বা জেসচার ব্যবহার করে কোনো অ্যাপ থেকে বের হওয়ার বর্তমান আচরণের সাথে মিলে যায়।
বেশিরভাগ অ্যাপের ক্ষেত্রে, এই পরিবর্তনের অর্থ হলো, যে ব্যবহারকারীরা আপনার অ্যাপ থেকে বের হওয়ার জন্য 'ব্যাক' বোতাম ব্যবহার করেন, তারা অ্যাপটিকে 'কোল্ড স্টেট' থেকে সম্পূর্ণভাবে পুনরায় চালু করার পরিবর্তে, 'ওয়ার্ম স্টেট' থেকে আরও দ্রুত অ্যাপটি আবার চালু করতে পারবেন।
আমরা এই পরিবর্তনটি সহ আপনার অ্যাপগুলো পরীক্ষা করার পরামর্শ দিচ্ছি। যদি আপনার অ্যাপ বর্তমানে ব্যাক নেভিগেশন পরিচালনা করতে এবং 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);
সংযোগ
পাসপোর্ট আপডেট
অ্যান্ড্রয়েড ১২-এ নিম্নলিখিত এপিআইগুলো যুক্ত করা হয়েছে:
-
isPasspointTermsAndConditionsSupported(): শর্তাবলী হলো পাসপয়েন্টের একটি ফিচার, যা নেটওয়ার্ক ডেপ্লয়মেন্টকে অনিরাপদ ক্যাপটিভ পোর্টাল (যা ওপেন নেটওয়ার্ক ব্যবহার করে) একটি নিরাপদ পাসপয়েন্ট নেটওয়ার্ক দিয়ে প্রতিস্থাপন করার সুযোগ দেয়। যখন শর্তাবলী গ্রহণ করার প্রয়োজন হয়, তখন ব্যবহারকারীকে একটি নোটিফিকেশন দেখানো হয়। যে অ্যাপগুলো শর্তাবলী দ্বারা নিয়ন্ত্রিত পাসপয়েন্ট নেটওয়ার্কের পরামর্শ দেয়, তাদের অবশ্যই প্রথমে এই API-টি কল করে নিশ্চিত করতে হবে যে ডিভাইসটি এই সক্ষমতা সমর্থন করে কিনা। যদি ডিভাইসটি এই সক্ষমতা সমর্থন না করে, তবে এটি এই নেটওয়ার্কে সংযোগ করতে পারবে না এবং একটি বিকল্প বা লিগ্যাসি নেটওয়ার্কের পরামর্শ দিতে হবে। isDecoratedIdentitySupported(): প্রিফিক্স ডেকোরেশন সহ নেটওয়ার্কগুলিতে প্রমাণীকরণের সময়, ডেকোরেটেড আইডেন্টিটি প্রিফিক্স নেটওয়ার্ক অপারেটরদের একটি AAA নেটওয়ার্কের অভ্যন্তরে একাধিক প্রক্সির মাধ্যমে সুস্পষ্ট রাউটিং সম্পাদন করার জন্য নেটওয়ার্ক অ্যাক্সেস আইডেন্টিফায়ার (NAI) আপডেট করার অনুমতি দেয় (এই বিষয়ে আরও জানতে RFC 7542 দেখুন)।অ্যান্ড্রয়েড ১২, PPS-MO এক্সটেনশনের জন্য WBA স্পেসিফিকেশনের সাথে সামঞ্জস্য রাখতে এই ফিচারটি প্রয়োগ করেছে। যেসব অ্যাপ এমন পাসপয়েন্ট নেটওয়ার্কের পরামর্শ দেয় যার জন্য ডেকোরেটেড আইডেন্টিটি প্রয়োজন, তাদের অবশ্যই প্রথমে এই API-টি কল করে নিশ্চিত করতে হবে যে ডিভাইসটি এই সক্ষমতা সমর্থন করে কি না। যদি ডিভাইসটি এই সক্ষমতা সমর্থন না করে, তবে আইডেন্টিটি ডেকোরেটেড হবে না এবং নেটওয়ার্কে অথেনটিকেশন ব্যর্থ হতে পারে।
একটি পাসপয়েন্ট সাজেশন তৈরি করতে, অ্যাপগুলিকে অবশ্যই PasspointConfiguration , Credential এবং HomeSp ক্লাসগুলি ব্যবহার করতে হবে। এই ক্লাসগুলি পাসপয়েন্ট প্রোফাইলের বর্ণনা দেয়, যা ওয়াই-ফাই অ্যালায়েন্স পাসপয়েন্ট স্পেসিফিকেশনে সংজ্ঞায়িত করা হয়েছে।
আরও তথ্যের জন্য, ইন্টারনেট সংযোগের জন্য ওয়াই-ফাই সাজেশন এপিআই দেখুন।
আপডেট করা নন-এসডিকে ইন্টারফেস সীমাবদ্ধতা
অ্যান্ড্রয়েড ডেভেলপারদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে অ্যান্ড্রয়েড ১২-এ সীমাবদ্ধ নন-এসডিকে ইন্টারফেসের হালনাগাদ তালিকা অন্তর্ভুক্ত করা হয়েছে। যখনই সম্ভব, আমরা নন-এসডিকে ইন্টারফেস সীমাবদ্ধ করার আগে নিশ্চিত করি যে সেগুলোর পাবলিক বিকল্প উপলব্ধ আছে।
আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১২-কে টার্গেট না করে, তবে এই পরিবর্তনগুলোর কিছু হয়তো আপনাকে তাৎক্ষণিকভাবে প্রভাবিত করবে না। তবে, যদিও আপনি বর্তমানে কিছু নন-এসডিকে ইন্টারফেস ব্যবহার করতে পারেন ( যা আপনার অ্যাপের টার্গেট এপিআই লেভেলের উপর নির্ভর করে ), যেকোনো নন-এসডিকে মেথড বা ফিল্ড ব্যবহার করলে আপনার অ্যাপটি ভেঙে যাওয়ার উচ্চ ঝুঁকি সবসময়ই থাকে।
আপনার অ্যাপ নন-এসডিকে ইন্টারফেস ব্যবহার করে কিনা, সে বিষয়ে আপনি অনিশ্চিত থাকলে, তা জানার জন্য আপনার অ্যাপটি পরীক্ষা করে দেখতে পারেন। যদি আপনার অ্যাপ নন-এসডিকে ইন্টারফেসের উপর নির্ভরশীল হয়, তবে আপনার এসডিকে বিকল্পগুলিতে স্থানান্তরের পরিকল্পনা শুরু করা উচিত। তা সত্ত্বেও, আমরা বুঝি যে কিছু অ্যাপের ক্ষেত্রে নন-এসডিকে ইন্টারফেস ব্যবহারের যৌক্তিক কারণ থাকে। যদি আপনি আপনার অ্যাপের কোনো ফিচারের জন্য নন-এসডিকে ইন্টারফেস ব্যবহারের কোনো বিকল্প খুঁজে না পান, তবে আপনার একটি নতুন পাবলিক এপিআই-এর জন্য অনুরোধ করা উচিত।
অ্যান্ড্রয়েডের এই সংস্করণের পরিবর্তনগুলো সম্পর্কে আরও জানতে, অ্যান্ড্রয়েড ১২-এ নন-এসডিকে ইন্টারফেস সীমাবদ্ধতার আপডেট দেখুন। সাধারণভাবে নন-এসডিকে ইন্টারফেস সম্পর্কে আরও জানতে, নন-এসডিকে ইন্টারফেসের উপর সীমাবদ্ধতা দেখুন।