অপ্ট-ইন বিজ্ঞপ্তির জন্য বিজ্ঞপ্তি অনুমতি

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

এই পৃষ্ঠাটি বর্ণনা করে যে এই পরিবর্তনটিকে সমর্থন করার জন্য OEM-গুলিকে কী প্রয়োগ করতে হবে এবং কীভাবে বাস্তবায়নকে বৈধ করতে হবে৷

অপ্ট-ইন বিজ্ঞপ্তিগুলির জন্য পরিবর্তনগুলি প্রয়োগ করুন৷

Android 13 দিয়ে শুরু করে, অ্যাপগুলিকে বিজ্ঞপ্তি পাঠানোর আগে সিস্টেম থেকে android.permission.POST_NOTIFICATION রানটাইম অনুমতির অনুরোধ করে বিজ্ঞপ্তি পাঠানোর তাদের অভিপ্রায় ঘোষণা করতে হবে।

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

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

একটি অপ্ট-ইন মডেলে ব্যবহারকারীর বিজ্ঞপ্তির আচরণ

নিম্নলিখিত সারণীটি Android 13 চালিত একটি ডিভাইসে বিভিন্ন অ্যাপ সংস্করণের জন্য বিজ্ঞপ্তি আচরণকে চিত্রিত করে:

Android 13 এ ডিভাইস	অ্যান্ড্রয়েড 13 বা উচ্চতরকে লক্ষ্য করে অ্যাপ	অ্যান্ড্রয়েড 13-এর চেয়ে কম সংস্করণগুলি লক্ষ্য করে এমন অ্যাপ
নতুন ইনস্টল	অ্যাপ দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি ব্লক করা হয়। কখন অনুমতি চাইতে হবে তা অ্যাপ নিয়ন্ত্রণ করে।	OS দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি অবরুদ্ধ করা হয়৷ অ্যাপটির প্রথম রানে অনুমতি চাওয়া হয়।
বিদ্যমান অ্যাপ (আপগ্রেড)	অ্যাপ দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি অনুমোদিত। অ্যাপটি প্রথম কোয়ালিফাইং রানে জিজ্ঞাসা না করা পর্যন্ত অস্থায়ী অনুমতি দেওয়া হয়।	OS দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি অনুমোদিত৷ অ্যাপটির প্রথম রান না হওয়া পর্যন্ত অস্থায়ী অনুমতি দেওয়া হয়।

বাস্তবায়নের জন্য নির্দেশিকা

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

বাস্তবায়নের সময়, Android 13 বা নিম্নতর SDK-কে টার্গেট করা অ্যাপগুলির জন্য ব্যবহারকারীর বিজ্ঞপ্তি আচরণের উপর নিম্নলিখিত নির্দেশিকাগুলি ব্যবহার করুন:

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

• অ্যান্ড্রয়েড 13-এ আপগ্রেড করার আগে ডিভাইসে বিদ্যমান যে কোনও অ্যাপ বা ব্যাকআপ এবং পুনরুদ্ধারের মাধ্যমে পুনরুদ্ধার করা হয়েছে এমন কোনও অ্যাপকে ব্যবহারকারী সেই অ্যাপ থেকে প্রথমবার কোনও কার্যকলাপ চালু না করা পর্যন্ত বিজ্ঞপ্তি পাঠানোর অনুমতি দিতে হবে।

  • যে অ্যাপগুলি Android 13 এবং উচ্চতর সংস্করণগুলির SDK কে লক্ষ্য করে, ব্যবহারকারী যদি অ্যাপ বা NotificationChannel স্তরে এই অ্যাপের জন্য পূর্বে বিজ্ঞপ্তি সেটিংস কাস্টমাইজ না করে থাকেন, তাহলে সাময়িক অনুমতি মঞ্জুরি প্রত্যাহার করুন। বিজ্ঞপ্তি পাঠানো চালিয়ে যাওয়ার অনুমতি দেওয়ার আগে অ্যাপগুলিকে অবশ্যই ব্যবহারকারীর অনুমতি চাইতে হবে।

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

  • যে অ্যাপগুলির জন্য Android 13-এর চেয়ে কম সংস্করণগুলির একটি লক্ষ্য SDK আছে, ব্যবহারকারী অ্যাপ থেকে বিজ্ঞপ্তি পেতে চান কিনা তা জিজ্ঞাসা করার জন্য একটি অনুমতি প্রম্পট দেখানোর জন্য অ্যাপটি কমপক্ষে একটি NotificationChannel তৈরি করার পরে প্রথম অ্যাক্টিভিটি লঞ্চে বাধা দেয় ।

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

• ব্যাকআপ এবং পুনরুদ্ধার অবশ্যই একটি Android 13 ডিভাইস এবং একটি পূর্ববর্তী OS সংস্করণের একটি ডিভাইসের মধ্যে পিছনে এবং ফরওয়ার্ড সামঞ্জস্যপূর্ণ হতে হবে। একটি Android 13 ডিভাইস থেকে উৎপন্ন ব্যাকআপ ডেটা অবশ্যই পূর্বের OS সংস্করণে পুনরুদ্ধার করতে হবে এবং পূর্ববর্তী OS সংস্করণ থেকে ব্যাকআপ ডেটা অবশ্যই একটি Android 13 ডিভাইসে পুনরুদ্ধার করতে হবে।

• চলমান মিডিয়া প্লেব্যাকের সাথে যুক্ত মিডিয়া বিজ্ঞপ্তিগুলিকে অবশ্যই বিজ্ঞপ্তির অনুমতি থেকে অব্যাহতি দিতে হবে।

বিজ্ঞপ্তি এবং অনুমতি সিস্টেমের পরিবর্তন যাচাই করুন

বাস্তবায়ন যাচাই করতে, নিম্নলিখিত পরীক্ষা চালান:

• PreferencesHelperTest , NotificationManagerServiceTest এ নির্দিষ্ট করা ইউনিট পরীক্ষা।

• যে কোনো ম্যানুয়াল পরীক্ষা যা আপগ্রেড এবং ব্যাকআপ এবং পুনরুদ্ধার পরীক্ষা করে।

• যেকোনো CTS অনুমতি এবং বিজ্ঞপ্তি সিস্টেম পরীক্ষা যা বিজ্ঞপ্তি পাঠায়। এর মধ্যে কিছু পরীক্ষা cts/tests/tests/permission/ , NotificationManagerTest.java , এবং cts/tests/tests/notificationlegacy/ -এ অবস্থিত।

,

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

এই পৃষ্ঠাটি বর্ণনা করে যে এই পরিবর্তনটিকে সমর্থন করার জন্য OEM-গুলিকে কী প্রয়োগ করতে হবে এবং কীভাবে বাস্তবায়নকে বৈধ করতে হবে৷

অপ্ট-ইন বিজ্ঞপ্তিগুলির জন্য পরিবর্তনগুলি প্রয়োগ করুন৷

Android 13 দিয়ে শুরু করে, অ্যাপগুলিকে বিজ্ঞপ্তি পাঠানোর আগে সিস্টেম থেকে android.permission.POST_NOTIFICATION রানটাইম অনুমতির অনুরোধ করে বিজ্ঞপ্তি পাঠানোর তাদের অভিপ্রায় ঘোষণা করতে হবে।

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

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

একটি অপ্ট-ইন মডেলে ব্যবহারকারীর বিজ্ঞপ্তির আচরণ

নিম্নলিখিত সারণীটি Android 13 চালিত একটি ডিভাইসে বিভিন্ন অ্যাপ সংস্করণের জন্য বিজ্ঞপ্তি আচরণকে চিত্রিত করে:

Android 13 এ ডিভাইস	অ্যান্ড্রয়েড 13 বা উচ্চতরকে লক্ষ্য করে অ্যাপ	অ্যান্ড্রয়েড 13-এর চেয়ে কম সংস্করণগুলি লক্ষ্য করে এমন অ্যাপ
নতুন ইনস্টল	অ্যাপ দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি ব্লক করা হয়। কখন অনুমতি চাইতে হবে তা অ্যাপ নিয়ন্ত্রণ করে।	OS দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি অবরুদ্ধ করা হয়৷ অ্যাপটির প্রথম রানে অনুমতি চাওয়া হয়।
বিদ্যমান অ্যাপ (আপগ্রেড)	অ্যাপ দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি অনুমোদিত। অ্যাপটি প্রথম কোয়ালিফাইং রানে জিজ্ঞাসা না করা পর্যন্ত অস্থায়ী অনুমতি দেওয়া হয়।	OS দ্বারা অনুরোধ না করা পর্যন্ত বিজ্ঞপ্তিগুলি অনুমোদিত৷ অ্যাপটির প্রথম রান না হওয়া পর্যন্ত অস্থায়ী অনুমতি দেওয়া হয়।

বাস্তবায়নের জন্য নির্দেশিকা

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

বাস্তবায়নের সময়, Android 13 বা নিম্নতর SDK-কে টার্গেট করা অ্যাপগুলির জন্য ব্যবহারকারীর বিজ্ঞপ্তি আচরণের উপর নিম্নলিখিত নির্দেশিকাগুলি ব্যবহার করুন:

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

• অ্যান্ড্রয়েড 13-এ আপগ্রেড করার আগে ডিভাইসে বিদ্যমান যে কোনও অ্যাপ বা ব্যাকআপ এবং পুনরুদ্ধারের মাধ্যমে পুনরুদ্ধার করা হয়েছে এমন কোনও অ্যাপকে ব্যবহারকারী সেই অ্যাপ থেকে প্রথমবার কোনও কার্যকলাপ চালু না করা পর্যন্ত বিজ্ঞপ্তি পাঠানোর অনুমতি দিতে হবে।

  • যে অ্যাপগুলি Android 13 এবং উচ্চতর সংস্করণগুলির SDK কে লক্ষ্য করে, ব্যবহারকারী যদি অ্যাপ বা NotificationChannel স্তরে এই অ্যাপের জন্য পূর্বে বিজ্ঞপ্তি সেটিংস কাস্টমাইজ না করে থাকেন, তাহলে সাময়িক অনুমতি মঞ্জুরি প্রত্যাহার করুন। বিজ্ঞপ্তি পাঠানো চালিয়ে যাওয়ার অনুমতি দেওয়ার আগে অ্যাপগুলিকে অবশ্যই ব্যবহারকারীর অনুমতি চাইতে হবে।

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

  • যে অ্যাপগুলির জন্য Android 13-এর চেয়ে কম সংস্করণগুলির একটি লক্ষ্য SDK আছে, ব্যবহারকারী অ্যাপ থেকে বিজ্ঞপ্তি পেতে চান কিনা তা জিজ্ঞাসা করার জন্য একটি অনুমতি প্রম্পট দেখানোর জন্য অ্যাপটি কমপক্ষে একটি NotificationChannel তৈরি করার পরে প্রথম অ্যাক্টিভিটি লঞ্চে বাধা দেয় ।

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

• ব্যাকআপ এবং পুনরুদ্ধার অবশ্যই একটি Android 13 ডিভাইস এবং একটি পূর্ববর্তী OS সংস্করণের একটি ডিভাইসের মধ্যে পিছনে এবং ফরওয়ার্ড সামঞ্জস্যপূর্ণ হতে হবে। একটি Android 13 ডিভাইস থেকে উৎপন্ন ব্যাকআপ ডেটা অবশ্যই পূর্বের OS সংস্করণে পুনরুদ্ধার করতে হবে এবং পূর্ববর্তী OS সংস্করণ থেকে ব্যাকআপ ডেটা অবশ্যই একটি Android 13 ডিভাইসে পুনরুদ্ধার করতে হবে।

• চলমান মিডিয়া প্লেব্যাকের সাথে যুক্ত মিডিয়া বিজ্ঞপ্তিগুলিকে অবশ্যই বিজ্ঞপ্তির অনুমতি থেকে অব্যাহতি দিতে হবে।

বিজ্ঞপ্তি এবং অনুমতি সিস্টেমের পরিবর্তন যাচাই করুন

বাস্তবায়ন যাচাই করতে, নিম্নলিখিত পরীক্ষা চালান:

• PreferencesHelperTest , NotificationManagerServiceTest এ নির্দিষ্ট করা ইউনিট পরীক্ষা।

• যে কোনো ম্যানুয়াল পরীক্ষা যা আপগ্রেড এবং ব্যাকআপ এবং পুনরুদ্ধার পরীক্ষা করে।

• যেকোনো CTS অনুমতি এবং বিজ্ঞপ্তি সিস্টেম পরীক্ষা যা বিজ্ঞপ্তি পাঠায়। এর মধ্যে কিছু পরীক্ষা cts/tests/tests/permission/ , NotificationManagerTest.java , এবং cts/tests/tests/notificationlegacy/ -এ অবস্থিত।