আচরণে পরিবর্তন: Android 12-কে টার্গেট করা অ্যাপ

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

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

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

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

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

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

এইভাবে, Android 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 ব্যবহার করতে চাইবেন যাতে নিশ্চিত করা যায় যে কলাপ্স করা ও বড় করা অবস্থা সামঞ্জস্যপূর্ণ।

    • "Heads Up" স্টেট আপনার প্রত্যাশা অনুযায়ী কাজ করছে কিনা তা নিশ্চিত করতে, বিজ্ঞপ্তি চ্যানেলের গুরুত্ব "HIGH" (স্ক্রিনে পপ-আপ করে) করতে ভুলবেন না।

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

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

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

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

Android 12-এ ছবির-মধ্যে-ছবি (PiP) মোডের জন্য আচরণগত উন্নতি এবং জেসচার নেভিগেশন ও এলিমেন্ট-ভিত্তিক নেভিগেশন, উভয়ের জন্যই ট্রানজিশন অ্যানিমেশনের ক্ষেত্রে সাজসজ্জা সংক্রান্ত উন্নতি সাজেস্ট করা হয়েছে।

আরও তথ্যের জন্য ছবির-মধ্যে-ছবি ফিচারে করা উন্নতি দেখুন।

Toast রিডিজাইন

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

Android ডিভাইসের ছবি যেখানে অ্যাপ আইকনের পাশে 'মেসেজ পাঠানো হচ্ছে' লেখা টোস্ট পপ-আপ দেখানো হচ্ছে

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

নিরাপত্তা ও গোপনীয়তা

আনুমানিক লোকেশন

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

WebView-তে আধুনিক SameSite কুকি

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

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

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

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

এইসব পরিবর্তনের ব্যাপারে ওয়েব ডেভেলপারদের জন্য সম্পূর্ণ নির্দেশিকা পেতে, SameSite কুকি ব্যাখ্যা করা হয়েছে এবং 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-এর মধ্যে Android 12 (API লেভেল ৩১) টার্গেট করার জন্য আপনার অ্যাপ কম্পাইল করুন।

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

Android-এ WebView-এর জন্য রিমোট ডিবাগিং সম্পর্কে তথ্যের জন্য, Android ডিভাইসের রিমোট ডিবাগিংয়ের মাধ্যমে শুরু করুন দেখুন।

অন্যান্য রিসোর্স

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

মোশন সেন্সরের রেট সীমিত করা হয়েছে

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

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

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

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

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

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

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

আপনার অ্যাপ Android ১২ বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করলে, আপনাকে অবশ্যই অ্যাপের ম্যানিফেস্ট ফাইলে এইসব অ্যাট্রিবিউশন ট্যাগ উল্লেখ করতে হবে।

ADB ব্যাক-আপ সংক্রান্ত বিধিনিষেধ

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

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

আরও নিরাপদ কম্পোনেন্ট এক্সপোর্ট করা হচ্ছে

আপনার অ্যাপ Android ১২ বা তার পরবর্তী কোনও ভার্সনকে টার্গেট করলে এবং তাতে অ্যাক্টিভিটি, পরিষেবা বা ব্রডকাস্ট রিসিভার থাকলে, যা ইনটেন্ট ফিল্টার ব্যবহার করে, তাহলে আপনাকে অবশ্যই স্পষ্টভাবে এইসব অ্যাপ কম্পোনেন্টের জন্য 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 Studio-তে মেসেজ

আপনার অ্যাপে যদি এমন কোনও অ্যাক্টিভিটি, পরিষেবা বা ব্রডকাস্ট রিসিভার থাকে যা ইনটেন্ট ফিল্টার ব্যবহার করে কিন্তু android:exported ঘোষণা করে না, তাহলে আপনি Android Studio-এর যে ভার্সন ব্যবহার করেন তার উপর নির্ভর করে নিম্নলিখিত সতর্কতামূলক মেসেজ দেখানো হয়:

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.
Android Studio-এর পুরনো ভার্সন

আপনি অ্যাপ ইনস্টল করার চেষ্টা করলে, 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 ১২-কে টার্গেট করলে, আপনার অ্যাপের তৈরি করা প্রতিটি PendingIntent অবজেক্টের মিউটেবিলিটি নির্দিষ্ট করতে হবে। এই অতিরিক্ত প্রয়োজনীয়তা আপনার অ্যাপের নিরাপত্তা উন্নত করে।

পেন্ডিং ইনটেন্ট মিউটেবিলিটি পরিবর্তন টেস্ট করুন

আপনার অ্যাপে মিউটেবিলিটি ডিক্লারেশন মিসিং আছে কিনা তা নির্ধারণ করতে, Android Studio-তে নিম্নলিখিত লিন্ট সংক্রান্ত সতর্কতা খুঁজুন:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

নিরাপদ নয় এমন ইনটেন্ট লঞ্চ

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

পারফর্ম্যান্স

ফোরগ্রাউন্ড পরিষেবা লঞ্চ করার বিধিনিষেধ

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

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

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

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

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

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

আচরণ পরিবর্তন বন্ধ করুন

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

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

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

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

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

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

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

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

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

D2D ট্রান্সফার ফাংশনালিটিতে পরিবর্তন

Android 12 এবং তার পরবর্তী যেকোনও ভার্সনে রান করা এবং টার্গেট করা অ্যাপের জন্য:

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

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

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

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

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

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

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

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

কনকারেন্ট পিয়ার-টু-পিয়ার + ইন্টারনেট কানেকশন

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

মানানসই

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

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

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

নিম্নলিখিত কোড স্যাম্পেল থেকে জানা যায় যে কীভাবে WifiInfo-কে NetworkCallback-এ পাওয়া যায়:

Kotlin

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

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

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

ভেন্ডর লাইব্রেরি

ভেন্ডরের দেওয়া নেটিভ শেয়ার করা লাইব্রেরি

অ্যাপ Android ১২ (API লেভেল ৩১) বা তার পরবর্তী ভার্সনকে টার্গেট করলে, সিলিকন ভেন্ডর বা ডিভাইস প্রস্তুতকারকের দেওয়া NDK-নেটিভ নয় এমন শেয়ার করা লাইব্রেরি ডিফল্ট হিসেবে অ্যাক্সেস করা যায় না। <uses-native-library> ট্যাগ ব্যবহার করে স্পষ্টভাবে অনুরোধ করা হলে তবেই লাইব্রেরি অ্যাক্সেস করা যায়।

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

SDK নয় এমন বিধিনিষেধ আপডেট করা হয়েছে

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

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

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

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