আচরণ পরিবর্তন: অ্যাপ্লিকেশানগুলি লক্ষ্য করে Android 12, আচরণের পরিবর্তনগুলি: Android 12 কে লক্ষ্য করে অ্যাপগুলি

পূর্ববর্তী রিলিজের মতো, Android 12-তেও আচরণগত পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণগত পরিবর্তনগুলি কেবলমাত্র Android 12 বা তার উচ্চতর সংস্করণগুলিকে লক্ষ্য করে এমন অ্যাপগুলির ক্ষেত্রে প্রযোজ্য। যদি আপনার অ্যাপটি Android 12-কে লক্ষ্য করে থাকে, তাহলে প্রযোজ্য ক্ষেত্রে এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য আপনার অ্যাপটি পরিবর্তন করা উচিত।

অ্যান্ড্রয়েড ১২-তে চলমান সমস্ত অ্যাপকে প্রভাবিত করে এমন আচরণগত পরিবর্তনের তালিকাটিও পর্যালোচনা করতে ভুলবেন না।

ব্যবহারকারীর অভিজ্ঞতা

কাস্টম বিজ্ঞপ্তি

অ্যান্ড্রয়েড ১২ সম্পূর্ণ কাস্টম নোটিফিকেশনের চেহারা এবং আচরণ পরিবর্তন করে। পূর্বে, কাস্টম নোটিফিকেশনগুলি সম্পূর্ণ নোটিফিকেশন এরিয়া ব্যবহার করতে এবং তাদের নিজস্ব লেআউট এবং স্টাইল প্রদান করতে সক্ষম ছিল। এর ফলে অ্যান্টি-প্যাটার্ন তৈরি হয়েছিল যা ব্যবহারকারীদের বিভ্রান্ত করতে পারে বা বিভিন্ন ডিভাইসে লেআউট সামঞ্জস্যের সমস্যা তৈরি করতে পারে।

অ্যান্ড্রয়েড ১২ টার্গেট করা অ্যাপগুলির জন্য, কাস্টম কন্টেন্ট ভিউ সহ বিজ্ঞপ্তিগুলি আর সম্পূর্ণ বিজ্ঞপ্তি এলাকা ব্যবহার করবে না; পরিবর্তে, সিস্টেমটি একটি স্ট্যান্ডার্ড টেমপ্লেট প্রয়োগ করে। এই টেমপ্লেটটি নিশ্চিত করে যে কাস্টম বিজ্ঞপ্তিগুলিতে সমস্ত রাজ্যে অন্যান্য বিজ্ঞপ্তিগুলির মতো একই সাজসজ্জা থাকবে, যেমন বিজ্ঞপ্তির আইকন এবং সম্প্রসারণ সুবিধা (ধরা অবস্থায়) এবং বিজ্ঞপ্তির আইকন, অ্যাপের নাম এবং ধরা অবস্থায় (ধরা অবস্থায়)। এই আচরণটি Notification.DecoratedCustomViewStyle এর আচরণের সাথে প্রায় একই রকম।

এইভাবে, অ্যান্ড্রয়েড ১২ ব্যবহারকারীদের জন্য একটি আবিষ্কারযোগ্য, পরিচিত বিজ্ঞপ্তি সম্প্রসারণের মাধ্যমে সমস্ত বিজ্ঞপ্তি দৃশ্যত সামঞ্জস্যপূর্ণ এবং স্ক্যান করা সহজ করে তোলে।

নিম্নলিখিত চিত্রটি স্ট্যান্ডার্ড টেমপ্লেটে একটি কাস্টম বিজ্ঞপ্তি দেখায়:

নিচের উদাহরণগুলি দেখায় যে কাস্টম বিজ্ঞপ্তিগুলি কীভাবে আড়াল এবং প্রসারিত অবস্থায় রেন্ডার হবে:

Android 12-এর পরিবর্তনটি Notification.Style এর কাস্টম সাবক্লাস সংজ্ঞায়িত করে এমন অ্যাপগুলিকে প্রভাবিত করে, অথবা Notification.Builder এর পদ্ধতিগুলি setCustomContentView(RemoteViews) , setCustomBigContentView(RemoteViews) এবং setCustomHeadsUpContentView(RemoteViews) ব্যবহার করে।

যদি আপনার অ্যাপটি সম্পূর্ণ কাস্টম বিজ্ঞপ্তি ব্যবহার করে, তাহলে আমরা যত তাড়াতাড়ি সম্ভব নতুন টেমপ্লেটটি পরীক্ষা করার পরামর্শ দিচ্ছি।

1. কাস্টম বিজ্ঞপ্তি পরিবর্তন সক্ষম করুন:

   1. নতুন আচরণটি সক্ষম করতে আপনার অ্যাপের targetSdkVersion S এ পরিবর্তন করুন।
   2. পুনরায় কম্পাইল করুন।
   3. Android 12 চালিত কোনও ডিভাইস বা এমুলেটরে আপনার অ্যাপটি ইনস্টল করুন।

2. কাস্টম ভিউ ব্যবহার করে এমন সমস্ত বিজ্ঞপ্তি পরীক্ষা করুন, যাতে সেগুলি ছায়ায় আপনার প্রত্যাশার মতো দেখায়। পরীক্ষা করার সময়, এই বিবেচনাগুলি বিবেচনা করুন এবং প্রয়োজনীয় সমন্বয় করুন:

   • কাস্টম ভিউয়ের মাত্রা পরিবর্তিত হয়েছে। সাধারণভাবে, কাস্টম নোটিফিকেশনের উচ্চতা আগের তুলনায় কম। কোলাপসড অবস্থায়, কাস্টম কন্টেন্টের সর্বোচ্চ উচ্চতা ১০৬ ডিপি থেকে ৪৮ ডিপিতে কমে গেছে। এছাড়াও, অনুভূমিক স্থানও কম।

   • Android 12-কে লক্ষ্য করে তৈরি অ্যাপগুলির জন্য সমস্ত বিজ্ঞপ্তি সম্প্রসারণযোগ্য। সাধারণত, এর অর্থ হল আপনি যদি setCustomContentView ব্যবহার করেন, তাহলে আপনাকে setBigCustomContentView ব্যবহার করতে হবে যাতে নিশ্চিত করা যায় যে collapsed এবং expanded অবস্থা সামঞ্জস্যপূর্ণ।

   • "হেডস আপ" অবস্থাটি আপনার প্রত্যাশা অনুযায়ী দেখানোর জন্য, বিজ্ঞপ্তি চ্যানেলের গুরুত্ব "হাই" (স্ক্রিনে পপ আপ) এ উন্নীত করতে ভুলবেন না।

অ্যান্ড্রয়েড অ্যাপ লিংক যাচাইকরণের পরিবর্তনগুলি

অ্যান্ড্রয়েড ১২ বা তার পরবর্তী ভার্সনের অ্যাপগুলিতে, সিস্টেমটি অ্যান্ড্রয়েড অ্যাপ লিঙ্কগুলি কীভাবে যাচাই করা হয় তাতে বেশ কয়েকটি পরিবর্তন করে। এই পরিবর্তনগুলি অ্যাপ-লিঙ্কিং অভিজ্ঞতার নির্ভরযোগ্যতা উন্নত করে এবং অ্যাপ ডেভেলপার এবং শেষ ব্যবহারকারীদের আরও নিয়ন্ত্রণ প্রদান করে।

যদি আপনি আপনার অ্যাপে ওয়েব লিঙ্ক খোলার জন্য Android App Link যাচাইকরণের উপর নির্ভর করেন, তাহলে Android App Link যাচাইকরণের জন্য ইন্টেন্ট ফিল্টার যোগ করার সময় সঠিক ফর্ম্যাট ব্যবহার করছেন কিনা তা পরীক্ষা করে দেখুন। বিশেষ করে, নিশ্চিত করুন যে এই ইন্টেন্ট ফিল্টারগুলিতে BROWSABLE বিভাগ অন্তর্ভুক্ত রয়েছে এবং https স্কিম সমর্থন করে।

আপনার ঘোষণার নির্ভরযোগ্যতা পরীক্ষা করার জন্য আপনি আপনার অ্যাপের লিঙ্কগুলি ম্যানুয়ালি যাচাই করতে পারেন।

ছবিতে-মধ্যে-ছবি আচরণের উন্নতি

অ্যান্ড্রয়েড ১২ পিকচার-ইন-পিকচার (পিআইপি) মোডের জন্য আচরণগত উন্নতি প্রবর্তন করেছে এবং অঙ্গভঙ্গি নেভিগেশন এবং উপাদান-ভিত্তিক নেভিগেশন উভয়ের জন্য ট্রানজিশন অ্যানিমেশনে কসমেটিক উন্নতির সুপারিশ করেছে।

আরও তথ্যের জন্য ছবিতে ছবির উন্নতি দেখুন।

টোস্টের নতুন নকশা

অ্যান্ড্রয়েড ১২-তে, টোস্ট ভিউটি নতুনভাবে ডিজাইন করা হয়েছে। টোস্টগুলি এখন দুটি লাইনের টেক্সটের মধ্যে সীমাবদ্ধ এবং টেক্সটের পাশে অ্যাপ্লিকেশন আইকনটি দেখায়।

আরও বিস্তারিত জানার জন্য টোস্টের ওভারভিউ দেখুন।

নিরাপত্তা এবং গোপনীয়তা

আনুমানিক অবস্থান

Android 12 বা তার পরবর্তী ভার্সন চালানো ডিভাইসগুলিতে, ব্যবহারকারীরা আপনার অ্যাপের জন্য আনুমানিক অবস্থানের নির্ভুলতার জন্য অনুরোধ করতে পারেন ।

WebView-এ আধুনিক SameSite কুকিজ

অ্যান্ড্রয়েডের ওয়েবভিউ কম্পোনেন্টটি ক্রোমিয়ামের উপর ভিত্তি করে তৈরি, যা গুগলের ক্রোম ব্রাউজারকে শক্তিশালী করে এমন একটি ওপেন সোর্স প্রকল্প। ক্রোমিয়াম আরও সুরক্ষা এবং গোপনীয়তা প্রদান এবং ব্যবহারকারীদের আরও স্বচ্ছতা এবং নিয়ন্ত্রণ প্রদানের জন্য তৃতীয় পক্ষের কুকিজ পরিচালনায় পরিবর্তন এনেছে। অ্যান্ড্রয়েড ১২ থেকে শুরু করে, যখন অ্যাপগুলি অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) বা তার বেশি টার্গেট করে তখন এই পরিবর্তনগুলি WebView অন্তর্ভুক্ত করা হয়।

কুকির SameSite অ্যাট্রিবিউট নিয়ন্ত্রণ করে যে এটি কোনও অনুরোধের সাথে পাঠানো যাবে কিনা, নাকি শুধুমাত্র একই সাইটের অনুরোধের সাথে পাঠানো যাবে। নিম্নলিখিত গোপনীয়তা-সুরক্ষা পরিবর্তনগুলি তৃতীয় পক্ষের কুকির ডিফল্ট পরিচালনা উন্নত করে এবং অনিচ্ছাকৃত ক্রস-সাইট শেয়ারিং থেকে রক্ষা করতে সাহায্য করে:

• SameSite অ্যাট্রিবিউট ছাড়া কুকিগুলিকে SameSite=Lax হিসেবে বিবেচনা করা হয়।
• SameSite=None এর কুকিজগুলিতে Secure অ্যাট্রিবিউটও নির্দিষ্ট করতে হবে, যার অর্থ তাদের একটি নিরাপদ প্রসঙ্গ প্রয়োজন এবং HTTPS এর মাধ্যমে পাঠানো উচিত।
• কোনও সাইটের HTTP এবং HTTPS সংস্করণের মধ্যে লিঙ্কগুলিকে এখন ক্রস-সাইট অনুরোধ হিসাবে বিবেচনা করা হয়, তাই কুকিগুলি যথাযথভাবে SameSite=None; Secure হিসাবে চিহ্নিত না করা পর্যন্ত পাঠানো হয় না।

ডেভেলপারদের জন্য, সাধারণ নির্দেশিকা হল আপনার গুরুত্বপূর্ণ ব্যবহারকারী প্রবাহে ক্রস-সাইট কুকি নির্ভরতা সনাক্ত করা এবং নিশ্চিত করা যে SameSite অ্যাট্রিবিউটটি স্পষ্টভাবে যথাযথ মান সহ সেট করা আছে যেখানে প্রয়োজন। আপনাকে অবশ্যই স্পষ্টভাবে নির্দিষ্ট করতে হবে যে কুকিগুলি ওয়েবসাইট জুড়ে বা HTTP থেকে HTTPS-এ স্থানান্তরিত একই-সাইট নেভিগেশন জুড়ে কাজ করার অনুমতিপ্রাপ্ত।

এই পরিবর্তনগুলি সম্পর্কে ওয়েব ডেভেলপারদের সম্পূর্ণ নির্দেশিকা জানতে, SameSite Cookies Explained এবং Schemeful SameSite দেখুন।

আপনার অ্যাপে SameSite আচরণ পরীক্ষা করুন

যদি আপনার অ্যাপ WebView ব্যবহার করে, অথবা আপনি যদি কুকি ব্যবহার করে এমন কোনও ওয়েবসাইট বা পরিষেবা পরিচালনা করেন, তাহলে আমরা Android 12 WebView-এ আপনার ফ্লো পরীক্ষা করার পরামর্শ দিচ্ছি। যদি আপনি কোনও সমস্যা খুঁজে পান, তাহলে নতুন SameSite আচরণ সমর্থন করার জন্য আপনার কুকিজ আপডেট করার প্রয়োজন হতে পারে।

লগইন এবং এমবেডেড কন্টেন্টের সমস্যাগুলির পাশাপাশি সাইন-ইন প্রবাহ, ক্রয় এবং অন্যান্য প্রমাণীকরণ প্রবাহের দিকে নজর রাখুন যেখানে ব্যবহারকারী একটি অনিরাপদ পৃষ্ঠা থেকে শুরু করে একটি নিরাপদ পৃষ্ঠায় স্থানান্তর করে।

WebView দিয়ে একটি অ্যাপ পরীক্ষা করার জন্য, আপনাকে যে অ্যাপটি পরীক্ষা করতে চান তার জন্য নতুন SameSite আচরণগুলি সক্ষম করতে হবে নিম্নলিখিত ধাপগুলির যেকোনো একটি সম্পূর্ণ করে:

• WebView devtools এ UI ফ্ল্যাগ webview-enable-modern-cookie-same-site টগল করে টেস্ট ডিভাইসে SameSite আচরণগুলি ম্যানুয়ালি সক্ষম করুন।

  এই পদ্ধতিটি আপনাকে Android 5.0 (API লেভেল 21) বা উচ্চতর সংস্করণে চলমান যেকোনো ডিভাইসে পরীক্ষা করতে দেয়—যার মধ্যে Android 12ও রয়েছে—এবং WebView সংস্করণ 89.0.4385.0 বা উচ্চতর সংস্করণ।

• targetSdkVersion ব্যবহার করে আপনার অ্যাপটি টার্গেট অ্যান্ড্রয়েড ১২ (API লেভেল ৩১) এর সাথে কম্পাইল করুন।

  আপনি যদি এই পদ্ধতিটি ব্যবহার করেন, তাহলে আপনাকে অবশ্যই এমন একটি ডিভাইস ব্যবহার করতে হবে যা Android 12 চালিত।

অ্যান্ড্রয়েডে ওয়েবভিউয়ের জন্য রিমোট ডিবাগিং সম্পর্কে তথ্যের জন্য, অ্যান্ড্রয়েড ডিভাইসগুলির রিমোট ডিবাগিং শুরু করুন দেখুন।

অন্যান্য সম্পদ

SameSite-এর আধুনিক আচরণ এবং Chrome এবং WebView-এ রোলআউট সম্পর্কে আরও তথ্যের জন্য, Chromium SameSite আপডেট পৃষ্ঠাটি দেখুন। যদি আপনি WebView বা Chromium-এ কোনও বাগ খুঁজে পান, তাহলে আপনি পাবলিক Chromium ইস্যু ট্র্যাকারে এটি রিপোর্ট করতে পারেন।

মোশন সেন্সরগুলি গতি-সীমাবদ্ধ

ব্যবহারকারীদের সম্পর্কে সম্ভাব্য সংবেদনশীল তথ্য সুরক্ষিত রাখতে, যদি আপনার অ্যাপটি অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণকে লক্ষ্য করে, তাহলে সিস্টেমটি নির্দিষ্ট মোশন সেন্সর এবং পজিশন সেন্সর থেকে ডেটা রিফ্রেশ রেটের উপর একটি সীমা নির্ধারণ করে।

সেন্সর রেট-লিমিটিং সম্পর্কে আরও জানুন।

অ্যাপ হাইবারনেশন

অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) তে প্রবর্তিত অনুমতি অটো-রিসেট আচরণের উপর ভিত্তি করে অ্যান্ড্রয়েড ১২ প্রসারিত হয়। যদি আপনার অ্যাপটি অ্যান্ড্রয়েড ১২ কে টার্গেট করে এবং ব্যবহারকারী কয়েক মাস ধরে আপনার অ্যাপের সাথে ইন্টারঅ্যাক্ট না করে, তাহলে সিস্টেমটি যেকোনো অনুমোদিত অনুমতি স্বয়ংক্রিয়ভাবে রিসেট করে এবং আপনার অ্যাপটিকে হাইবারনেশন অবস্থায় রাখে।

অ্যাপ হাইবারনেশন সম্পর্কে আরও জানুন।

ডেটা অ্যাক্সেস অডিটিংয়ে অ্যাট্রিবিউশন ঘোষণা

অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) এ প্রবর্তিত ডেটা অ্যাক্সেস অডিটিং এপিআই আপনাকে আপনার অ্যাপের ব্যবহারের ক্ষেত্রের উপর ভিত্তি করে অ্যাট্রিবিউশন ট্যাগ তৈরি করতে দেয়। এই ট্যাগগুলি আপনার অ্যাপের কোন অংশটি নির্দিষ্ট ধরণের ডেটা অ্যাক্সেস সম্পাদন করে তা নির্ধারণ করা সহজ করে তোলে।

যদি আপনার অ্যাপটি Android 12 বা তার পরবর্তী ভার্সনের জন্য তৈরি হয়, তাহলে আপনাকে অবশ্যই আপনার অ্যাপের ম্যানিফেস্ট ফাইলে এই অ্যাট্রিবিউশন ট্যাগগুলি ঘোষণা করতে হবে।

ADB ব্যাকআপ সীমাবদ্ধতা

ব্যক্তিগত অ্যাপ ডেটা সুরক্ষিত রাখতে, Android 12 adb backup কমান্ডের ডিফল্ট আচরণ পরিবর্তন করে। Android 12 (API লেভেল 31) বা তার বেশি ভার্সনের অ্যাপগুলির জন্য, যখন কোনও ব্যবহারকারী adb backup কমান্ড চালায়, তখন ডিভাইস থেকে রপ্তানি করা অন্য কোনও সিস্টেম ডেটা থেকে অ্যাপ ডেটা বাদ দেওয়া হয়।

যদি আপনার টেস্টিং বা ডেভেলপমেন্ট ওয়ার্কফ্লো adb backup ব্যবহার করে অ্যাপ ডেটার উপর নির্ভর করে, তাহলে আপনি এখন আপনার অ্যাপের ম্যানিফেস্ট ফাইলে android:debuggable কে true এ সেট করে আপনার অ্যাপের ডেটা এক্সপোর্ট করার বিকল্প বেছে নিতে পারেন।

নিরাপদে উপাদান রপ্তানি

যদি আপনার অ্যাপটি Android 12 বা তার পরবর্তী ভার্সনের জন্য তৈরি হয় এবং এতে এমন কার্যকলাপ , পরিষেবা বা ব্রডকাস্ট রিসিভার থাকে যা ইনটেন্ট ফিল্টার ব্যবহার করে, তাহলে আপনাকে অবশ্যই এই অ্যাপ উপাদানগুলির জন্য android:exported বৈশিষ্ট্যটি স্পষ্টভাবে ঘোষণা করতে হবে।

যদি অ্যাপ কম্পোনেন্টে LAUNCHER ক্যাটাগরি থাকে, android:exported কে true তে সেট করুন। অন্যান্য বেশিরভাগ ক্ষেত্রে, android:exported কে false তে সেট করুন।

নিচের কোড স্নিপেটটি এমন একটি পরিষেবার উদাহরণ দেখায় যেখানে একটি ইন্টেন্ট ফিল্টার রয়েছে যার android:exported অ্যাট্রিবিউট false তে সেট করা আছে:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

অ্যান্ড্রয়েড স্টুডিওতে বার্তা

যদি আপনার অ্যাপে এমন কোনও কার্যকলাপ, পরিষেবা, অথবা সম্প্রচার রিসিভার থাকে যা ইনটেন্ট ফিল্টার ব্যবহার করে কিন্তু android:exported ঘোষণা করে না, তাহলে আপনার ব্যবহৃত Android Studio এর সংস্করণের উপর নির্ভর করে নিম্নলিখিত সতর্কতা বার্তাগুলি প্রদর্শিত হবে:

অ্যান্ড্রয়েড স্টুডিও ২০২০.৩.১ ক্যানারি ১১ বা তার পরবর্তী সংস্করণ

নিম্নলিখিত বার্তাগুলি প্রদর্শিত হবে:

1. আপনার ম্যানিফেস্ট ফাইলে নিম্নলিখিত লিন্ট সতর্কতাটি প্রদর্শিত হবে:

   When using intent filters, please specify android:exported as well
   

2. যখন আপনি আপনার অ্যাপ কম্পাইল করার চেষ্টা করেন, তখন নিম্নলিখিত বিল্ড ত্রুটি বার্তাটি উপস্থিত হয়:

   Manifest merger failed : Apps targeting Android 12 and higher are required \
   to specify an explicit value for android:exported when the corresponding \
   component has an intent filter defined.
   

অ্যান্ড্রয়েড স্টুডিওর পুরোনো সংস্করণ

আপনি যদি অ্যাপটি ইনস্টল করার চেষ্টা করেন, Logcat নিম্নলিখিত ত্রুটি বার্তাটি প্রদর্শন করে:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

মুলতুবি থাকা ইন্টেন্টের পরিবর্তনযোগ্যতা

যদি আপনার অ্যাপটি Android 12-কে টার্গেট করে, তাহলে আপনার অ্যাপের তৈরি প্রতিটি PendingIntent অবজেক্টের পরিবর্তনযোগ্যতা নির্দিষ্ট করতে হবে। এই অতিরিক্ত প্রয়োজনীয়তা আপনার অ্যাপের নিরাপত্তা উন্নত করে।

মুলতুবি থাকা ইন্টেন্ট পরিবর্তনযোগ্যতা পরিবর্তন পরীক্ষা করুন

আপনার অ্যাপে মিউটিবিলিটি ডিক্লারেশন অনুপস্থিত কিনা তা নির্ধারণ করতে, অ্যান্ড্রয়েড স্টুডিওতে নিম্নলিখিত লিন্ট সতর্কতাটি দেখুন:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

অনিরাপদ অভিপ্রায় লঞ্চ

প্ল্যাটফর্মের নিরাপত্তা উন্নত করার জন্য, Android 12 এবং উচ্চতর সংস্করণগুলি একটি ডিবাগিং বৈশিষ্ট্য প্রদান করে যা অনিরাপদ লঞ্চের উদ্দেশ্য সনাক্ত করে । যখন সিস্টেমটি এই ধরনের একটি অনিরাপদ লঞ্চ সনাক্ত করে, তখন একটি StrictMode লঙ্ঘন ঘটে।

কর্মক্ষমতা

ফোরগ্রাউন্ড পরিষেবা চালু করার সীমাবদ্ধতা

অ্যান্ড্রয়েড ১২ বা তার উচ্চতর ভার্সনকে লক্ষ্য করে এমন অ্যাপগুলি ব্যাকগ্রাউন্ডে চলাকালীন ফোরগ্রাউন্ড পরিষেবা শুরু করতে পারে না, কিছু বিশেষ ক্ষেত্রে ছাড়া। যদি কোনও অ্যাপ ব্যাকগ্রাউন্ডে চলাকালীন ফোরগ্রাউন্ড পরিষেবা শুরু করার চেষ্টা করে, তবে একটি ব্যতিক্রম ঘটে (কয়েকটি বিশেষ ক্ষেত্রে ছাড়া)।

আপনার অ্যাপটি ব্যাকগ্রাউন্ডে চলাকালীন সময়সূচী নির্ধারণ এবং দ্রুত কাজ শুরু করার জন্য WorkManager ব্যবহার করার কথা বিবেচনা করুন। ব্যবহারকারীর অনুরোধ করা সময়-সংবেদনশীল ক্রিয়াগুলি সম্পন্ন করতে, একটি সঠিক অ্যালার্মের মধ্যে ফোরগ্রাউন্ড পরিষেবাগুলি শুরু করুন।

সঠিক অ্যালার্মের অনুমতি

অ্যাপগুলিকে সিস্টেম রিসোর্স সংরক্ষণে উৎসাহিত করার জন্য, যেসব অ্যাপ অ্যান্ড্রয়েড ১২ এবং তার উচ্চতর ভার্সনকে লক্ষ্য করে এবং সঠিক অ্যালার্ম সেট করে তাদের "অ্যালার্ম এবং রিমাইন্ডার" সক্ষমতা অ্যাক্সেস করতে হবে যা সিস্টেম সেটিংসে বিশেষ অ্যাপ অ্যাক্সেস স্ক্রিনে প্রদর্শিত হয়।

এই বিশেষ অ্যাপ অ্যাক্সেস পেতে, ম্যানিফেস্টে SCHEDULE_EXACT_ALARM অনুমতির অনুরোধ করুন।

সঠিক অ্যালার্মগুলি শুধুমাত্র ব্যবহারকারী-মুখী বৈশিষ্ট্যগুলির জন্য ব্যবহার করা উচিত। সঠিক অ্যালার্ম সেট করার জন্য গ্রহণযোগ্য ব্যবহারের ক্ষেত্রে আরও জানুন।

আচরণ পরিবর্তন অক্ষম করুন

অ্যান্ড্রয়েড ১২ টার্গেট করার জন্য আপনার অ্যাপ প্রস্তুত করার সময়, পরীক্ষার উদ্দেশ্যে আপনি আপনার ডিবাগেবল বিল্ড ভেরিয়েন্টে আচরণ পরিবর্তন সাময়িকভাবে অক্ষম করতে পারেন। এটি করার জন্য, নিম্নলিখিত কাজগুলির মধ্যে একটি সম্পূর্ণ করুন:

• ডেভেলপার অপশন সেটিং স্ক্রিনে, অ্যাপ কম্প্যাটিবিলিটি চেঞ্জ নির্বাচন করুন। যে স্ক্রিনটি প্রদর্শিত হবে, সেখানে আপনার অ্যাপের নামের উপর ট্যাপ করুন, তারপর REQUIRE_EXACT_ALARM_PERMISSION বন্ধ করুন।

• আপনার ডেভেলপমেন্ট মেশিনের একটি টার্মিনাল উইন্ডোতে, নিম্নলিখিত কমান্ডটি চালান:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

বিজ্ঞপ্তি ট্রাম্পোলিন বিধিনিষেধ

যখন ব্যবহারকারীরা বিজ্ঞপ্তিগুলির সাথে ইন্টারঅ্যাক্ট করে, তখন কিছু অ্যাপ একটি অ্যাপ কম্পোনেন্ট চালু করে নোটিফিকেশন ট্যাপের প্রতিক্রিয়া জানায় যা অবশেষে সেই কার্যকলাপ শুরু করে যা ব্যবহারকারী অবশেষে দেখে এবং ইন্টারঅ্যাক্ট করে। এই অ্যাপ কম্পোনেন্টটি একটি নোটিফিকেশন ট্রাম্পোলিন নামে পরিচিত।

অ্যাপের কর্মক্ষমতা এবং UX উন্নত করার জন্য, Android 12 বা উচ্চতর ভার্সনগুলিকে লক্ষ্য করে এমন অ্যাপগুলি পরিষেবা বা ব্রডকাস্ট রিসিভার থেকে কার্যকলাপ শুরু করতে পারে না যা বিজ্ঞপ্তি ট্রাম্পোলিন হিসাবে ব্যবহৃত হয়। অন্য কথায়, ব্যবহারকারী কোনও বিজ্ঞপ্তিতে বা বিজ্ঞপ্তির মধ্যে একটি অ্যাকশন বোতামে ট্যাপ করার পরে, আপনার অ্যাপ কোনও পরিষেবা বা ব্রডকাস্ট রিসিভারের ভিতরে startActivity() কল করতে পারবে না।

যখন আপনার অ্যাপটি কোনও পরিষেবা বা সম্প্রচার রিসিভার থেকে কোনও কার্যকলাপ শুরু করার চেষ্টা করে যা একটি বিজ্ঞপ্তি ট্রাম্পোলিন হিসাবে কাজ করে, তখন সিস্টেমটি কার্যকলাপটি শুরু হতে বাধা দেয় এবং Logcat- এ নিম্নলিখিত বার্তাটি উপস্থিত হয়:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

কোন অ্যাপের উপাদানগুলি বিজ্ঞপ্তি ট্রাম্পোলিন হিসেবে কাজ করে তা শনাক্ত করুন

আপনার অ্যাপটি পরীক্ষা করার সময়, কোনও বিজ্ঞপ্তিতে ট্যাপ করার পরে, আপনি সনাক্ত করতে পারবেন কোন পরিষেবা বা সম্প্রচার রিসিভার আপনার অ্যাপে বিজ্ঞপ্তি ট্রাম্পোলিন হিসাবে কাজ করেছে। এটি করার জন্য, নিম্নলিখিত টার্মিনাল কমান্ডের আউটপুটটি দেখুন:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

আউটপুটের একটি অংশে "NotifInteractionLog" লেখাটি রয়েছে। এই অংশে নোটিফিকেশন ট্যাপের ফলে শুরু হওয়া উপাদানটি সনাক্ত করার জন্য প্রয়োজনীয় তথ্য রয়েছে।

আপনার অ্যাপ আপডেট করুন

যদি আপনার অ্যাপটি এমন কোনও পরিষেবা বা সম্প্রচার রিসিভার থেকে কোনও কার্যকলাপ শুরু করে যা একটি বিজ্ঞপ্তি ট্রাম্পোলিন হিসাবে কাজ করে, তাহলে নিম্নলিখিত মাইগ্রেশন পদক্ষেপগুলি সম্পূর্ণ করুন:

1. একটি PendingIntent অবজেক্ট তৈরি করুন যা ব্যবহারকারীরা বিজ্ঞপ্তিতে ট্যাপ করার পরে যে কার্যকলাপটি দেখেন তার সাথে সম্পর্কিত।
2. আপনার বিজ্ঞপ্তি তৈরির অংশ হিসেবে পূর্ববর্তী ধাপে তৈরি করা PendingIntent অবজেক্টটি ব্যবহার করুন।

কার্যকলাপের উৎস শনাক্ত করতে, উদাহরণস্বরূপ লগিং করার জন্য, বিজ্ঞপ্তি পোস্ট করার সময় অতিরিক্ত ব্যবহার করুন। কেন্দ্রীভূত লগিংয়ের জন্য, ActivityLifecycleCallbacks অথবা Jetpack lifecycle observers ব্যবহার করুন।

আচরণটি টগল করুন

আপনার অ্যাপের ডিবাগযোগ্য সংস্করণ পরীক্ষা করার সময়, আপনি NOTIFICATION_TRAMPOLINE_BLOCK অ্যাপ সামঞ্জস্যতা পতাকা ব্যবহার করে এই সীমাবদ্ধতা সক্ষম এবং অক্ষম করতে পারেন।

ব্যাকআপ এবং পুনরুদ্ধার

অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) তে চলা এবং লক্ষ্য করে তৈরি অ্যাপগুলিতে ব্যাকআপ এবং রিস্টোর কীভাবে কাজ করে তাতে কিছু পরিবর্তন এসেছে। অ্যান্ড্রয়েড ব্যাকআপ এবং রিস্টোরের দুটি রূপ রয়েছে:

• ক্লাউড ব্যাকআপ: ব্যবহারকারীর ডেটা ব্যবহারকারীর গুগল ড্রাইভে সংরক্ষণ করা হয় যাতে পরে সেই ডিভাইসে বা নতুন ডিভাইসে পুনরুদ্ধার করা যায়।
• ডিভাইস-টু-ডিভাইস (D2D) ট্রান্সফার: ব্যবহারকারীর ডেটা সরাসরি তাদের পুরানো ডিভাইস থেকে ব্যবহারকারীর নতুন ডিভাইসে পাঠানো হয়, যেমন একটি কেবল ব্যবহার করে।

ডেটা কীভাবে ব্যাকআপ এবং পুনরুদ্ধার করা হয় সে সম্পর্কে আরও তথ্যের জন্য, অটো ব্যাকআপ ব্যবহার করে ব্যবহারকারীর ডেটা ব্যাকআপ করুন এবং অ্যান্ড্রয়েড ব্যাকআপ পরিষেবা ব্যবহার করে কী-মান জোড়া ব্যাকআপ করুন দেখুন।

D2D ট্রান্সফার কার্যকারিতা পরিবর্তন

Android 12 এবং তার পরবর্তী ভার্সনে চলমান এবং লক্ষ্যবস্তু করা অ্যাপগুলির জন্য:

• XML কনফিগারেশন মেকানিজমের সাথে অন্তর্ভুক্ত এবং বাদ দেওয়ার নিয়ম নির্দিষ্ট করলে D2D ট্রান্সফার প্রভাবিত হয় না, যদিও এটি এখনও ক্লাউড-ভিত্তিক ব্যাকআপ এবং পুনরুদ্ধারকে প্রভাবিত করে (যেমন Google ড্রাইভ ব্যাকআপ)। D2D ট্রান্সফারের জন্য নিয়ম নির্দিষ্ট করতে, আপনাকে পরবর্তী বিভাগে বর্ণিত নতুন কনফিগারেশন ব্যবহার করতে হবে।

• কিছু ডিভাইস প্রস্তুতকারকের ডিভাইসে, android:allowBackup="false" নির্দিষ্ট করলে Google ড্রাইভে ব্যাকআপ অক্ষম করা হয়, কিন্তু অ্যাপের জন্য D2D স্থানান্তর অক্ষম করা হয় না।

নতুন অন্তর্ভুক্ত এবং বাদ দেওয়ার ফর্ম্যাট

অ্যান্ড্রয়েড ১২ এবং তার পরবর্তী সংস্করণে চলমান এবং লক্ষ্যবস্তু করা অ্যাপগুলি XML কনফিগারেশনের জন্য একটি ভিন্ন ফর্ম্যাট ব্যবহার করে। এই ফর্ম্যাটটি Google ড্রাইভ ব্যাকআপ এবং D2D ট্রান্সফারের মধ্যে পার্থক্য স্পষ্ট করে তোলে, ক্লাউড ব্যাকআপ এবং D2D ট্রান্সফারের জন্য আপনাকে আলাদাভাবে অন্তর্ভুক্ত এবং বাদ দেওয়ার নিয়ম নির্দিষ্ট করতে হবে।

ঐচ্ছিকভাবে, আপনি ব্যাকআপের জন্য নিয়ম নির্দিষ্ট করতেও এটি ব্যবহার করতে পারেন, এই ক্ষেত্রে Android 12 বা তার বেশি ভার্সন চালানোর ডিভাইসগুলিতে পূর্বে ব্যবহৃত কনফিগারেশন উপেক্ষা করা হয়। Android 11 বা তার কম ভার্সন চালানোর ডিভাইসগুলির জন্য এখনও পুরানো কনফিগারেশন প্রয়োজন।

XML ফর্ম্যাট পরিবর্তন

অ্যান্ড্রয়েড ১১ এবং তার আগের ভার্সনে ব্যাকআপ এবং পুনরুদ্ধার কনফিগারেশনের জন্য ব্যবহৃত ফর্ম্যাটটি নিম্নরূপ:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

নিচে মোটা অক্ষরে বিন্যাসের পরিবর্তনগুলি দেখানো হল।

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

আরও তথ্যের জন্য, অটো ব্যাকআপের মাধ্যমে ব্যবহারকারীর ডেটা ব্যাকআপ করার নির্দেশিকার সংশ্লিষ্ট বিভাগটি দেখুন।

অ্যাপের জন্য ম্যানিফেস্ট ফ্ল্যাগ

আপনার ম্যানিফেস্ট ফাইলে android:dataExtractionRules অ্যাট্রিবিউট ব্যবহার করে আপনার অ্যাপগুলিকে নতুন XML কনফিগারেশনের দিকে নির্দেশ করুন। যখন আপনি নতুন XML কনফিগারেশনের দিকে নির্দেশ করেন, তখন Android 12 বা তার উচ্চতর ভার্সন চালিত ডিভাইসগুলিতে পুরানো কনফিগারেশনের দিকে নির্দেশ করে এমন android:fullBackupContent অ্যাট্রিবিউট উপেক্ষা করা হয়। নিম্নলিখিত কোড নমুনাটি নতুন ম্যানিফেস্ট ফাইল এন্ট্রিগুলি দেখায়:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

সংযোগ

ব্লুটুথ অনুমতি

অ্যান্ড্রয়েড ১২, BLUETOOTH_SCAN , BLUETOOTH_ADVERTISE , এবং BLUETOOTH_CONNECT অনুমতি প্রদান করে। এই অনুমতিগুলি অ্যান্ড্রয়েড ১২-কে লক্ষ্য করে তৈরি অ্যাপগুলির জন্য ব্লুটুথ ডিভাইসগুলির সাথে ইন্টারঅ্যাক্ট করা সহজ করে তোলে, বিশেষ করে যেসব অ্যাপের ডিভাইসের অবস্থান অ্যাক্সেসের প্রয়োজন হয় না।

আপনার ডিভাইসটিকে Android 12 বা তার পরবর্তী ভার্সনের জন্য প্রস্তুত করতে, আপনার অ্যাপের লজিক আপডেট করুন। ব্লুটুথ অনুমতির একটি লিগ্যাসি সেট ঘোষণা করার পরিবর্তে, আরও আধুনিক ব্লুটুথ অনুমতির একটি সেট ঘোষণা করুন।

সমসাময়িক পিয়ার-টু-পিয়ার + ইন্টারনেট সংযোগ

অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) বা তার বেশি ভার্সনের অ্যাপগুলির জন্য, যেসব ডিভাইস একযোগে পিয়ার-টু-পিয়ার এবং ইন্টারনেট সংযোগ সমর্থন করে, তারা পিয়ার ডিভাইস এবং প্রাথমিক ইন্টারনেট সরবরাহকারী নেটওয়ার্ক উভয়ের সাথেই একযোগে ওয়াই-ফাই সংযোগ বজায় রাখতে পারে, যার ফলে ব্যবহারকারীর অভিজ্ঞতা আরও নিরবচ্ছিন্ন হয়। অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) বা তার কম ভার্সনের অ্যাপগুলি এখনও লিগ্যাসি আচরণের সম্মুখীন হয়, যেখানে পিয়ার ডিভাইসের সাথে সংযোগ স্থাপনের আগে প্রাথমিক ওয়াই-ফাই নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হয়ে যায়।

সামঞ্জস্য

WifiManager.getConnectionInfo() শুধুমাত্র একটি নেটওয়ার্কের জন্য WifiInfo ফেরত দিতে সক্ষম। এই কারণে, Android 12 এবং উচ্চতর সংস্করণে API এর আচরণ নিম্নলিখিত উপায়ে পরিবর্তন করা হয়েছে:

• যদি শুধুমাত্র একটি Wi-Fi নেটওয়ার্ক উপলব্ধ থাকে, তাহলে এর WifiInfo ফেরত পাঠানো হয়।
• যদি একাধিক Wi-Fi নেটওয়ার্ক উপলব্ধ থাকে এবং কলিং অ্যাপটি একটি পিয়ার-টু-পিয়ার সংযোগ ট্রিগার করে, তাহলে পিয়ার ডিভাইসের সাথে সম্পর্কিত WifiInfo ফেরত পাঠানো হয়।
• যদি একাধিক Wi-Fi নেটওয়ার্ক উপলব্ধ থাকে এবং কলিং অ্যাপটি পিয়ার-টু-পিয়ার সংযোগ চালু না করে, তাহলে প্রাথমিক ইন্টারনেট সরবরাহকারী সংযোগের WifiInfo ফেরত পাঠানো হয়।

দ্বৈত একযোগে ওয়াই-ফাই নেটওয়ার্ক সমর্থন করে এমন ডিভাইসগুলিতে আরও ভালো ব্যবহারকারীর অভিজ্ঞতা প্রদানের জন্য, আমরা সমস্ত অ্যাপকে সুপারিশ করি—বিশেষ করে যেগুলি পিয়ার-টু-পিয়ার সংযোগ চালু করে— WifiManager.getConnectionInfo() কল করা থেকে দূরে সরে যান এবং পরিবর্তে NetworkCallback.onCapabilitiesChanged() ব্যবহার করুন যাতে NetworkCallback নিবন্ধন করতে ব্যবহৃত NetworkRequest সাথে মেলে এমন সমস্ত WifiInfo অবজেক্ট পাওয়া যায়। Android 12 থেকে getConnectionInfo() বন্ধ করা হয়েছে।

নিম্নলিখিত কোড নমুনাটি দেখায় কিভাবে একটি NetworkCallback এ WifiInfo পেতে হয়:

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

mDNSResponder নেটিভ API

অ্যান্ড্রয়েড ১২-তে mDNSResponder নেটিভ API ব্যবহার করে অ্যাপগুলি mDNSResponder ডেমনের সাথে ইন্টারঅ্যাক্ট করতে পারে কিনা তা পরিবর্তন করা হয়। পূর্বে, যখন কোনও অ্যাপ নেটওয়ার্কে একটি পরিষেবা নিবন্ধিত করত এবং getSystemService() পদ্ধতিতে কল করত, তখন সিস্টেমের NSD পরিষেবা mDNSResponder ডেমন শুরু করত, এমনকি অ্যাপটি এখনও কোনও NsdManager পদ্ধতিতে কল না করলেও। এরপর ডেমনটি ডিভাইসটিকে অল-নোড মাল্টিকাস্ট গ্রুপে সাবস্ক্রাইব করে, যার ফলে সিস্টেমটি আরও ঘন ঘন জাগ্রত হয় এবং অতিরিক্ত শক্তি ব্যবহার করে। ব্যাটারির ব্যবহার কমাতে, অ্যান্ড্রয়েড ১২ এবং উচ্চতর সংস্করণে সিস্টেম এখন শুধুমাত্র NSD ইভেন্টের জন্য প্রয়োজন হলে mDNSResponder ডেমন শুরু করে এবং পরে এটি বন্ধ করে দেয়।

যেহেতু এই পরিবর্তনটি mDNSResponder ডেমন উপলব্ধ থাকাকালীন প্রভাবিত করে, তাই যেসব অ্যাপ ধরে নেয় যে getSystemService() পদ্ধতিতে কল করার পরে mDNSResponder ডেমন শুরু হবে, তারা সিস্টেম থেকে এমন বার্তা পেতে পারে যে mDNSResponder ডেমন উপলব্ধ নয়। যেসব অ্যাপ NsdManager ব্যবহার করে এবং mDNSResponder নেটিভ API ব্যবহার করে না, তারা এই পরিবর্তনের দ্বারা প্রভাবিত হয় না।

বিক্রেতা লাইব্রেরি

বিক্রেতা-সরবরাহকৃত নেটিভ শেয়ার্ড লাইব্রেরি

সিলিকন বিক্রেতা বা ডিভাইস নির্মাতাদের দ্বারা সরবরাহিত নন-এনডিকে নেটিভ শেয়ার্ড লাইব্রেরিগুলি ডিফল্টরূপে অ্যাক্সেসযোগ্য নয় যদি অ্যাপটি অ্যান্ড্রয়েড 12 (এপিআই লেভেল 31) বা তার বেশি টার্গেট করে। লাইব্রেরিগুলি কেবল তখনই অ্যাক্সেসযোগ্য যখন সেগুলি <uses-native-library> ট্যাগ ব্যবহার করে স্পষ্টভাবে অনুরোধ করা হয়।

যদি অ্যাপটি অ্যান্ড্রয়েড ১১ (এপিআই লেভেল ৩০) বা তার নিচের ভার্সনের জন্য তৈরি হয়, তাহলে <uses-native-library> ট্যাগের প্রয়োজন নেই। সেক্ষেত্রে, যেকোনো নেটিভ শেয়ার্ড লাইব্রেরি এনডিকে লাইব্রেরি যাই হোক না কেন, অ্যাক্সেসযোগ্য।

আপডেট করা নন-SDK বিধিনিষেধ

অ্যান্ড্রয়েড ১২-তে অ্যান্ড্রয়েড ডেভেলপারদের সাথে সহযোগিতা এবং সর্বশেষ অভ্যন্তরীণ পরীক্ষার উপর ভিত্তি করে সীমাবদ্ধ নন-SDK ইন্টারফেসের আপডেট করা তালিকা অন্তর্ভুক্ত রয়েছে। যখনই সম্ভব, আমরা নিশ্চিত করি যে নন-SDK ইন্টারফেস সীমাবদ্ধ করার আগে সর্বজনীন বিকল্পগুলি উপলব্ধ রয়েছে।

যদি আপনার অ্যাপটি Android 12-কে টার্গেট না করে, তাহলে এই পরিবর্তনগুলির কিছু তাৎক্ষণিকভাবে আপনার উপর প্রভাব ফেলতে পারে না। তবে, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API স্তরের উপর নির্ভর করে ), যেকোনো নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে আপনার অ্যাপটি ভেঙে যাওয়ার ঝুঁকি সবসময় বেশি থাকে।

যদি আপনার অ্যাপটি নন-SDK ইন্টারফেস ব্যবহার করে কিনা তা নিশ্চিত না হন, তাহলে আপনি আপনার অ্যাপটি পরীক্ষা করে দেখতে পারেন। যদি আপনার অ্যাপ নন-SDK ইন্টারফেসের উপর নির্ভর করে, তাহলে আপনার SDK বিকল্পগুলিতে মাইগ্রেশনের পরিকল্পনা শুরু করা উচিত। তবুও, আমরা বুঝতে পারি যে কিছু অ্যাপের নন-SDK ইন্টারফেস ব্যবহারের জন্য বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। যদি আপনি আপনার অ্যাপে কোনও বৈশিষ্ট্যের জন্য নন-SDK ইন্টারফেস ব্যবহারের বিকল্প খুঁজে না পান, তাহলে আপনার একটি নতুন পাবলিক API অনুরোধ করা উচিত।

অ্যান্ড্রয়েডের এই রিলিজে পরিবর্তনগুলি সম্পর্কে আরও জানতে, অ্যান্ড্রয়েড ১২-তে নন-এসডিকে ইন্টারফেস সীমাবদ্ধতার আপডেটগুলি দেখুন। সাধারণত নন-এসডিকে ইন্টারফেস সম্পর্কে আরও জানতে, নন-এসডিকে ইন্টারফেসের উপর বিধিনিষেধগুলি দেখুন।