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

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

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

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

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

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

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

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

নিম্নলিখিত উদাহরণে স্ট্যান্ডার্ড টেমপ্লেটে একটি কাস্টম নোটিফিকেশন দেখানো হয়েছে:

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

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

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

1. কাস্টম নোটিফিকেশন পরিবর্তন সক্রিয় করুন:

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

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

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

   • অ্যান্ড্রয়েড ১২-এর জন্য তৈরি অ্যাপগুলোতে সমস্ত নোটিফিকেশন এক্সপ্যান্ড করা যায়। সাধারণত, এর মানে হলো, আপনি যদি setCustomContentView ব্যবহার করেন, তাহলে সংকুচিত এবং প্রসারিত অবস্থা সামঞ্জস্যপূর্ণ রাখতে আপনাকে setBigCustomContentView ও ব্যবহার করতে হবে।

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

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

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

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

আপনার ডিক্লারেশনগুলোর নির্ভরযোগ্যতা যাচাই করার জন্য আপনি ম্যানুয়ালিও আপনার অ্যাপের লিঙ্কগুলো ভেরিফাই করতে পারেন।

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

অ্যান্ড্রয়েড ১২ পিকচার-ইন-পিকচার (PiP) মোডের কার্যকারিতায় উন্নতি এনেছে, এবং জেসচার নেভিগেশন ও এলিমেন্ট-ভিত্তিক নেভিগেশন উভয়ের ট্রানজিশন অ্যানিমেশনের জন্য কিছু বাহ্যিক উন্নতির সুপারিশ করা হয়েছে।

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

টোস্টের নতুন ডিজাইন

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

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

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

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

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

ওয়েবভিউতে আধুনিক SameSite কুকি

অ্যান্ড্রয়েডের WebView কম্পোনেন্টটি ক্রোমিয়ামের উপর ভিত্তি করে তৈরি, যা একটি ওপেন সোর্স প্রজেক্ট এবং গুগলের ক্রোম ব্রাউজারকে শক্তি জোগায়। ক্রোমিয়াম থার্ড-পার্টি কুকি পরিচালনার ক্ষেত্রে কিছু পরিবর্তন এনেছে, যা আরও বেশি নিরাপত্তা ও গোপনীয়তা প্রদান করে এবং ব্যবহারকারীদের আরও বেশি স্বচ্ছতা ও নিয়ন্ত্রণ দেয়। অ্যান্ড্রয়েড ১২ থেকে, যখন অ্যাপগুলো অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) বা তার উচ্চতর সংস্করণকে টার্গেট করে, তখন এই পরিবর্তনগুলো 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- এ webview-enable-modern-cookie-same-site UI ফ্ল্যাগটি টগল করে টেস্ট ডিভাইসে ম্যানুয়ালি SameSite আচরণ সক্রিয় করুন।

  এই পদ্ধতিটি আপনাকে অ্যান্ড্রয়েড ৫.০ (এপিআই লেভেল ২১) বা তার উচ্চতর সংস্করণ—অ্যান্ড্রয়েড ১২ সহ—এবং ওয়েবভিউ সংস্করণ ৮৯.০.৪৩৮৫.০ বা তার উচ্চতর সংস্করণে চালিত যেকোনো ডিভাইসে পরীক্ষা করার সুযোগ দেয়।

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

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

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

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

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

মোশন সেন্সরগুলির হার সীমিত।

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

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

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

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

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

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

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

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

এডিবি ব্যাকআপ সীমাবদ্ধতা

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

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

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

আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণকে টার্গেট করে এবং এতে এমন অ্যাক্টিভিটি , সার্ভিস বা ব্রডকাস্ট রিসিভার থাকে যেগুলো ইন্টেন্ট ফিল্টার ব্যবহার করে, তাহলে আপনাকে অবশ্যই এই অ্যাপ কম্পোনেন্টগুলোর জন্য 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 ডিক্লেয়ার করে না, তাহলে আপনার ব্যবহৃত অ্যান্ড্রয়েড স্টুডিও-র ভার্সনের উপর নির্ভর করে নিম্নলিখিত সতর্কীকরণ বার্তাগুলো প্রদর্শিত হবে:

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

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

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'

অপেক্ষাধীন অভিপ্রায়ের পরিবর্তনযোগ্যতা

আপনার অ্যাপটি যদি অ্যান্ড্রয়েড ১২-কে টার্গেট করে, তবে আপনার অ্যাপ দ্বারা তৈরি প্রতিটি PendingIntent অবজেক্টের পরিবর্তনযোগ্যতা (mutability) অবশ্যই নির্দিষ্ট করতে হবে। এই অতিরিক্ত আবশ্যকতাটি আপনার অ্যাপের নিরাপত্তা বৃদ্ধি করে।

অপেক্ষাধীন অভিপ্রায় পরিবর্তনযোগ্যতা পরীক্ষা করুন

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

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

কর্মক্ষমতা

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

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

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

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

অ্যাপগুলিকে সিস্টেম রিসোর্স সংরক্ষণে উৎসাহিত করতে, যে অ্যাপগুলি অ্যান্ড্রয়েড ১২ বা তার পরবর্তী সংস্করণকে লক্ষ্য করে তৈরি এবং সুনির্দিষ্ট অ্যালার্ম সেট করে, সেগুলির সিস্টেম সেটিংসের ' স্পেশাল অ্যাপ অ্যাক্সেস' স্ক্রিনে প্রদর্শিত 'অ্যালার্মস অ্যান্ড রিমাইন্ডারস' সুবিধাটিতে অ্যাক্সেস থাকতে হবে।

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

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

আচরণ পরিবর্তন নিষ্ক্রিয় করুন

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

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

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

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

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

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

অ্যাপের পারফরম্যান্স এবং ইউএক্স (UX) উন্নত করার জন্য, অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলো নোটিফিকেশন ট্রাম্পোলিন হিসেবে ব্যবহৃত সার্ভিস বা ব্রডকাস্ট রিসিভার থেকে অ্যাক্টিভিটি শুরু করতে পারে না। অন্য কথায়, ব্যবহারকারী কোনো নোটিফিকেশনে বা তার ভেতরের কোনো অ্যাকশন বাটনে ট্যাপ করার পর, আপনার অ্যাপ কোনো সার্ভিস বা ব্রডকাস্ট রিসিভারের ভেতর থেকে 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 অ্যাপ সামঞ্জস্যতা ফ্ল্যাগ ব্যবহার করে এই সীমাবদ্ধতাটি সক্রিয় এবং নিষ্ক্রিয় করতে পারেন।

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

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

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

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

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

যেসব অ্যাপ অ্যান্ড্রয়েড ১২ বা তার পরবর্তী সংস্করণে চলে এবং সেগুলোকে লক্ষ্য করে তৈরি, তাদের জন্য:

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

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

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

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

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

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 পারমিশনগুলো চালু করা হয়েছে। এই পারমিশনগুলো অ্যান্ড্রয়েড ১২-এর জন্য তৈরি অ্যাপগুলোর পক্ষে ব্লুটুথ ডিভাইসের সাথে যোগাযোগ করা সহজ করে তোলে, বিশেষ করে সেইসব অ্যাপের জন্য যাদের ডিভাইসের লোকেশন অ্যাক্সেসের প্রয়োজন হয় না।

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

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

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

সামঞ্জস্যতা

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

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

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

নিম্নলিখিত কোড নমুনাটি দেখায় কিভাবে একটি 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 নেটিভ এপিআই

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

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

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

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

সিলিকন ভেন্ডর বা ডিভাইস প্রস্তুতকারকদের সরবরাহ করা নন-এনডিকে নেটিভ শেয়ার্ড লাইব্রেরিগুলো ডিফল্টরূপে অ্যাক্সেসযোগ্য হয় না, যদি অ্যাপটি অ্যান্ড্রয়েড ১২ (এপিআই লেভেল ৩১) বা তার উচ্চতর সংস্করণকে টার্গেট করে। লাইব্রেরিগুলো কেবল তখনই অ্যাক্সেসযোগ্য হয় যখন <uses-native-library> ট্যাগ ব্যবহার করে সেগুলোর জন্য সুস্পষ্টভাবে অনুরোধ করা হয়।

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

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

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

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

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

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