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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • কাস্টম ভিউ এর মাত্রা পরিবর্তিত হয়েছে. সাধারণভাবে, কাস্টম বিজ্ঞপ্তিগুলির উচ্চতা আগের তুলনায় কম৷ সঙ্কুচিত অবস্থায়, কাস্টম বিষয়বস্তুর সর্বোচ্চ উচ্চতা 106dp থেকে 48dp পর্যন্ত কমে গেছে। এছাড়াও, কম অনুভূমিক স্থান আছে।

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

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

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

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

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

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

পিকচার-ইন-পিকচার আচরণের উন্নতি

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

আরও তথ্যের জন্য পিকচার-ইন-পিকচার উন্নতি দেখুন।

টোস্ট পুনরায় নকশা

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

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

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

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

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

WebView-এ আধুনিক একইসাইট কুকিজ

অ্যান্ড্রয়েডের ওয়েবভিউ উপাদানটি ক্রোমিয়ামের উপর ভিত্তি করে তৈরি করা হয়েছে, এটি ওপেন সোর্স প্রকল্প যা Google-এর ক্রোম ব্রাউজারকে শক্তি দেয়৷ Chromium আরো নিরাপত্তা ও গোপনীয়তা প্রদান করতে এবং ব্যবহারকারীদের আরো স্বচ্ছতা ও নিয়ন্ত্রণ প্রদানের জন্য তৃতীয় পক্ষের কুকিজ পরিচালনায় পরিবর্তন এনেছে। Android 12 থেকে শুরু করে, অ্যাপগুলি Android 12 (API স্তর 31) বা উচ্চতরকে লক্ষ্য করলে এই পরিবর্তনগুলি WebView এও অন্তর্ভুক্ত করা হয়।

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

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

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

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

আপনার অ্যাপে একইসাইট আচরণ পরীক্ষা করুন

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

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

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

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

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

• targetSdkVersion দ্বারা Android 12 (API লেভেল 31) টার্গেট করতে আপনার অ্যাপ কম্পাইল করুন।

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

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

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

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

মোশন সেন্সর রেট-সীমিত

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

সেন্সর হার-সীমাবদ্ধতা সম্পর্কে আরও জানুন।

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

Android 12 অনুমতি স্বয়ংক্রিয়-রিসেট আচরণের উপর প্রসারিত হয় যা Android 11 (API স্তর 30) এ চালু করা হয়েছিল। যদি আপনার অ্যাপটি Android 12-কে টার্গেট করে এবং ব্যবহারকারী কয়েক মাস ধরে আপনার অ্যাপের সাথে ইন্টারঅ্যাক্ট না করে, তাহলে সিস্টেম স্বয়ংক্রিয়ভাবে প্রদত্ত অনুমতিগুলিকে রিসেট করে এবং আপনার অ্যাপটিকে হাইবারনেশন অবস্থায় রাখে।

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

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

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

যদি আপনার অ্যাপটি 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 to true সেট করুন। বেশিরভাগ অন্যান্য ক্ষেত্রে, সেট করুন android:exported to 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 স্টুডিও ব্যবহার করেন তার উপর নির্ভর করে নিম্নলিখিত সতর্কতা বার্তাগুলি উপস্থিত হয়:

Android Studio 2020.3.1 Canary 11 বা তার পরে

নিম্নলিখিত বার্তা উপস্থিত হয়:

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 অবজেক্টের পরিবর্তনযোগ্যতা নির্দিষ্ট করতে হবে। এই অতিরিক্ত প্রয়োজনীয়তা আপনার অ্যাপের নিরাপত্তা উন্নত করে।

মুলতুবি অভিপ্রায় পরিবর্তনশীলতা পরিবর্তন পরীক্ষা করুন

আপনার অ্যাপ পরিবর্তনযোগ্যতা ঘোষণা অনুপস্থিত কিনা তা নির্ধারণ করতে, Android স্টুডিওতে নিম্নলিখিত লিন্ট সতর্কতা দেখুন:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

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

কর্মক্ষমতা

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

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

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

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

অ্যাপ্লিকেশানগুলিকে সিস্টেম সংস্থানগুলি সংরক্ষণ করতে উত্সাহিত করতে, যে সমস্ত অ্যাপগুলি Android 12 এবং উচ্চতরকে লক্ষ্য করে এবং সঠিক অ্যালার্ম সেট করে তাদের অবশ্যই "অ্যালার্ম এবং অনুস্মারক" ক্ষমতার অ্যাক্সেস থাকতে হবে যা সিস্টেম সেটিংসে বিশেষ অ্যাপ অ্যাক্সেস স্ক্রিনের মধ্যে প্রদর্শিত হয়৷

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

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

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

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

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

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

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

বিজ্ঞপ্তি trampoline সীমাবদ্ধতা

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

অ্যাপের পারফরম্যান্স এবং 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 লাইফসাইকেল পর্যবেক্ষক ব্যবহার করুন।

আচরণ টগল করুন

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

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

Android 12 (API লেভেল 31) চালু এবং টার্গেট করা অ্যাপগুলিতে কীভাবে ব্যাকআপ এবং পুনরুদ্ধার কাজ করে তার পরিবর্তন রয়েছে। অ্যান্ড্রয়েড ব্যাকআপ এবং পুনরুদ্ধারের দুটি ফর্ম রয়েছে:

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

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

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

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

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

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

নতুন অন্তর্ভুক্ত এবং বাদ বিন্যাস

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

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

XML বিন্যাস পরিবর্তন

অ্যান্ড্রয়েড 11 এবং তার নিচের সংস্করণগুলিতে ব্যাকআপ এবং পুনরুদ্ধার কনফিগারেশনের জন্য নিম্নলিখিত ফর্ম্যাটটি ব্যবহার করা হয়েছে:

<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:fullBackupContent অ্যাট্রিবিউট যা পুরানো কনফিগারেশনের দিকে নির্দেশ করে Android 12 বা উচ্চতর সংস্করণে চলমান ডিভাইসগুলিতে উপেক্ষা করা হয়। নিম্নলিখিত কোড নমুনা নতুন ম্যানিফেস্ট ফাইল এন্ট্রি দেখায়:

<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>

সংযোগ

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

Android 12 BLUETOOTH_SCAN , BLUETOOTH_ADVERTISE , এবং BLUETOOTH_CONNECT অনুমতিগুলি প্রবর্তন করে৷ এই অনুমতিগুলি Android 12 কে লক্ষ্য করে এমন অ্যাপ্লিকেশানগুলিকে ব্লুটুথ ডিভাইসের সাথে ইন্টারঅ্যাক্ট করা সহজ করে তোলে, বিশেষ করে এমন অ্যাপগুলির জন্য যেগুলির ডিভাইসের অবস্থানে অ্যাক্সেসের প্রয়োজন নেই৷

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

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

অ্যান্ড্রয়েড 12 (এপিআই লেভেল 31) বা উচ্চতর টার্গেট করা অ্যাপ্লিকেশানগুলির জন্য, সমসাময়িক পিয়ার-টু-পিয়ার এবং ইন্টারনেট সংযোগ সমর্থন করে এমন ডিভাইসগুলি পিয়ার ডিভাইস এবং প্রাথমিক ইন্টারনেট-প্রদানকারী নেটওয়ার্ক উভয়ের সাথে একযোগে ওয়াই-ফাই সংযোগ বজায় রাখতে পারে, যা ব্যবহারকারীর অভিজ্ঞতাকে আরও বেশি করে তোলে। বিরামহীন Android 11 (API লেভেল 30) বা তার নিচের অ্যাপ্লিকেশানগুলি এখনও লিগ্যাসি আচরণের অভিজ্ঞতা লাভ করে, যেখানে পিয়ার ডিভাইসে সংযোগ করার আগে প্রাথমিক Wi-Fi নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হয়ে যায়।

সামঞ্জস্য

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

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

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

নিম্নলিখিত কোড নমুনা দেখায় কিভাবে একটি 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 ডেমনের সাথে ইন্টারঅ্যাক্ট করতে পারে তখন Android 12 পরিবর্তন হয়। পূর্বে, যখন একটি অ্যাপ নেটওয়ার্কে একটি পরিষেবা নিবন্ধিত করত এবং getSystemService() পদ্ধতিতে কল করত, তখন সিস্টেমের NSD পরিষেবা mDNSResponder ডেমন শুরু করত, এমনকি অ্যাপটি এখনও NsdManager পদ্ধতিতে কল না করলেও। ডেমন তখন ডিভাইসটিকে অল-নোড মাল্টিকাস্ট গ্রুপে সাবস্ক্রাইব করে, যার ফলে সিস্টেমটি আরও ঘন ঘন জেগে ওঠে এবং অতিরিক্ত শক্তি ব্যবহার করে। ব্যাটারি ব্যবহার কমাতে, Android 12 এবং উচ্চতর সিস্টেমে এখন mDNSResponder ডেমন চালু হয় যখন এটি NSD ইভেন্টের জন্য প্রয়োজন হয় এবং পরে এটি বন্ধ করে দেয়।

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

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

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

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

অ্যাপটি যদি Android 11 (API লেভেল 30) বা তার নিচের দিকে লক্ষ্য করে, তাহলে <uses-native-library> ট্যাগের প্রয়োজন নেই। সেক্ষেত্রে, যেকোন নেটিভ শেয়ার করা লাইব্রেরি সেটি একটি NDK লাইব্রেরিই হোক না কেন অ্যাক্সেসযোগ্য।

নন-SDK সীমাবদ্ধতা আপডেট করা হয়েছে

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

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

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

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