আচরণগত পরিবর্তন: Android 13 বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপ

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

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

গোপনীয়তা

বিজ্ঞপ্তির অনুমতি ফোরগ্রাউন্ড সার্ভিসের উপস্থিতিকে প্রভাবিত করে

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

আশেপাশের ওয়াই-ফাই ডিভাইসের জন্য নতুন রানটাইম অনুমতি

Android-এর আগের ভার্সনে, ব্যবহারকারীকে আপনার অ্যাপকে ACCESS_FINE_LOCATION অনুমতি দিতে হবে যাতে ওয়াই-ফাই ব্যবহারের সাধারণ কেস সম্পূর্ণ করা যায়।

ব্যবহারকারীদের পক্ষে ওয়াই-ফাই কার্যকারিতার সাথে লোকেশন সংক্রান্ত অনুমতি অ্যাসোসিয়েট করা কঠিন, তাই Android 13 (API লেভেল 33) ভার্সনে NEARBY_DEVICES অনুমতি গ্রুপে রানটাইম অনুমতি যোগ করা হয়েছে। এটি ওয়াই-ফাইয়ের মাধ্যমে আশেপাশের অ্যাক্সেস পয়েন্টের সাথে ডিভাইসের কানেকশন ম্যানেজ করে এমন অ্যাপের জন্য প্রযোজ্য। এই অনুমতি, NEARBY_WIFI_DEVICES, ওয়াই-ফাই ব্যবহারের ক্ষেত্রে নিম্নলিখিত বিষয়গুলি পূরণ করে:

• প্রিন্টার বা মিডিয়া কাস্টিং ডিভাইসের মতো আশেপাশের ডিভাইস খুঁজুন বা কানেক্ট করুন। এই ওয়ার্কফ্লো আপনার অ্যাপকে এই ধরনের কাজ করতে দেয়:
  • BLE-এর মতো আউট-অফ-ব্যান্ড থেকে AP সংক্রান্ত তথ্য পান।
  • Wi-Fi Aware-এর মাধ্যমে ডিভাইস খুঁজে কানেক্ট করুন এবং শুধুমাত্র-লোকাল হটস্পট ব্যবহার করে কানেক্ট করুন।
  • Wi-Fi ডাইরেক্টের মাধ্যমে ডিভাইস খুঁজে কানেক্ট করুন।
• গাড়ি বা স্মার্ট হোম ডিভাইসের মতো পরিচিত SSID-এর সাথে কানেকশন শুরু করুন।
• শুধুমাত্র লোকাল হটস্পট চালু করুন।
• আশেপাশের Wi-Fi Aware ডিভাইসের রেঞ্জ।

আপনার অ্যাপ যতক্ষণ পর্যন্ত ওয়াই-ফাই API থেকে ফিজিক্যাল লোকেশন সংক্রান্ত তথ্য না পায়, ততক্ষণ পর্যন্ত Android 13 বা তার পরবর্তী ভার্সন টার্গেট করার সময় এবং ওয়াই-ফাই API ব্যবহার করার সময় ACCESS_FINE_LOCATION-এর পরিবর্তে NEARBY_WIFI_DEVICES-এর জন্য অনুরোধ করুন। আপনি যখন NEARBY_WIFI_DEVICES অনুমতি ঘোষণা করেন, তখন দৃঢ়ভাবে দাবি করেন যে আপনার অ্যাপ কখনই ওয়াই-ফাই API থেকে ফিজিক্যাল লোকেশন সংক্রান্ত তথ্য সংগ্রহ করে না। এটি করতে, android:usesPermissionFlags অ্যাট্রিবিউট neverForLocation-এ সেট করুন। এই প্রসেসটি Android 12 (API লেভেল 31) এবং তার পরবর্তী ভার্সনে আপনি যা করেন তার মতোই, যখন আপনি নিশ্চিত করেন যে ব্লুটুথ ডিভাইসের তথ্য লোকেশনের জন্য কখনও ব্যবহার করা হয় না।

আশেপাশের ওয়াই-ফাই ডিভাইস অ্যাক্সেস করার অনুমতি কীভাবে চাইবেন সেই সম্পর্কে আরও জানুন।

বিভিন্ন লেভেলে মিডিয়া অ্যাক্সেস করার অনুমতি

আপনার অ্যাপ Android 13 বা এর পরের যেকোনও ভার্সনকে টার্গেট করলে এবং অন্য অ্যাপের তৈরি করা মিডিয়া ফাইল অ্যাক্সেস করতে হলে, READ_EXTERNAL_STORAGE অনুমতির পরিবর্তে আপনাকে নিম্নলিখিত এক বা একাধিক গ্র্যানুলার মিডিয়া অনুমতির জন্য অনুরোধ করতে হবে:

অন্য অ্যাপের মিডিয়া ফাইল অ্যাক্সেস করার আগে, ব্যবহারকারী আপনার অ্যাপকে উপযুক্ত গ্র্যানুলার মিডিয়া অনুমতি দিয়েছেন কিনা তা যাচাই করুন।

ছবি ১-এ এমন একটি অ্যাপ দেখানো হয়েছে যা READ_MEDIA_AUDIO অনুমতি চায়।

আপনি একই সময়ে READ_MEDIA_IMAGES অনুমতি এবং READ_MEDIA_VIDEO অনুমতি, দুটিই অনুরোধ করলে, শুধুমাত্র একটি সিস্টেম অনুমতি ডায়ালগ দেখানো হয়।

আপনার অ্যাপকে আগে READ_EXTERNAL_STORAGE অনুমতি দেওয়া হয়ে থাকলে, আপগ্রেড করার সময় অনুরোধ করা যেকোনও READ_MEDIA_* অনুমতি অটোমেটিক দেওয়া হয়। আপগ্রেড করা অনুমতি পর্যালোচনা করতে আপনি নিম্নলিখিত ADB কমান্ড ব্যবহার করতে পারেন:

adb shell cmd appops get --uid PACKAGE_NAME

ব্যাকগ্রাউন্ডে বডি সেন্সর ব্যবহার করার জন্য নতুন অনুমতি প্রয়োজন

Android 13-এ "ব্যবহার করার সময়" অ্যাক্সেসের ধারণা চালু করা হয়েছে। হার্ট রেট, তাপমাত্রা এবং রক্তে অক্সিজেনের পরিমাণের শতাংশের মতো বডি সেন্সরের ক্ষেত্রে এটি প্রযোজ্য। এই অ্যাক্সেস মডেলটি Android ১০ (API লেভেল ২৯)-এ লোকেশনের জন্য সিস্টেমের চালু করা মডেলের সাথে খুব মিল।

আপনার অ্যাপ Android ১৩ ভার্সনকে টার্গেট করলে এবং ব্যাকগ্রাউন্ডে চলার সময় বডি সেন্সর তথ্য অ্যাক্সেস করার প্রয়োজন হলে, আপনাকে অবশ্যই আগে থেকে থাকা BODY_SENSORS অনুমতির পাশাপাশি নতুন BODY_SENSORS_BACKGROUND অনুমতি ঘোষণা করতে হবে।

পারফর্ম্যান্স ও ব্যাটারি

ব্যাটারি রিসোর্স ব্যবহার

আপনার অ্যাপ Android 13-কে টার্গেট করার সময় ব্যাকগ্রাউন্ডে ব্যাটারি ব্যবহারের জন্য ব্যবহারকারী আপনার অ্যাপকে "সীমাবদ্ধ" অবস্থায় রাখলে, অন্য কোনও কারণে অ্যাপ চালু না করা পর্যন্ত সিস্টেম BOOT_COMPLETED ব্রডকাস্ট বা LOCKED_BOOT_COMPLETED ব্রডকাস্ট ডেলিভার করে না।

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

PlaybackState থেকে মিডিয়া কন্ট্রোল নেওয়া হয়েছে

Android 13 (API লেভেল 33) এবং তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপের জন্য, সিস্টেম PlaybackState অ্যাকশন থেকে মিডিয়া কন্ট্রোল নির্ণয় করে। এর ফলে, সিস্টেম আরও বেশি কন্ট্রোল দেখাতে পারে যা ফোন ও ট্যাবলেট ডিভাইসের মধ্যে টেকনিক্যালি একই রকম এবং Android Auto ও Android TV-র মতো অন্যান্য Android প্ল্যাটফর্মে মিডিয়া কন্ট্রোল যেভাবে দেখানো হয় তার সাথেও সামঞ্জস্যপূর্ণ।

ফোন ও ট্যাবলেট ডিভাইসে এটি কেমন দেখায় তার উদাহরণ যথাক্রমে ছবি ২-এ দেখানো হয়েছে।

Android 13-এর আগে, সিস্টেম MediaStyle বিজ্ঞপ্তি থেকে সর্বাধিক পাঁচটি অ্যাকশন দেখাত, যে ক্রমে সেগুলি যোগ করা হয়েছিল। কমপ্যাক্ট মোডে—যেমন, দ্রুত সেটিংস আড়াল করা থাকলে—setShowActionsInCompactView()-এর মাধ্যমে নির্দিষ্ট করা তিনটি পর্যন্ত অ্যাকশন দেখানো হয়।

Android 13 থেকে শুরু করে, সিস্টেম PlaybackState-এর উপর ভিত্তি করে সর্বাধিক পাঁচটি অ্যাকশন বোতাম দেখায় যেমনটি নিম্নলিখিত সারণীতে বর্ণনা করা হয়েছে। কমপ্যাক্ট মোডে, শুধুমাত্র প্রথম তিনটি অ্যাকশন স্লট দেখানো হবে। যেসব অ্যাপ Android 13-কে টার্গেট করে না অথবা যেগুলিতে PlaybackState অন্তর্ভুক্ত নেই, সিস্টেম সেগুলির ক্ষেত্রে পূর্ববর্তী অনুচ্ছেদে বর্ণিত MediaStyle বিজ্ঞপ্তিতে যোগ করা Action তালিকার উপর ভিত্তি করে কন্ট্রোল দেখাবে।

কাস্টম অ্যাকশনগুলি যে ক্রমে PlaybackState-এ যোগ করা হয়েছে সেই ক্রমে রাখা হয়েছে।

অ্যাপের রঙের থিম WebView কন্টেন্টে অটোমেটিক প্রয়োগ করা হয়

Android 13 (API লেভেল 33) বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপের ক্ষেত্রে, setForceDark() পদ্ধতিটি বাতিল করা হয়েছে, যার ফলে পদ্ধতিটি কল করা হলে কোনও অপারেশন হয় না।

পরিবর্তে, WebView এখন সবসময় অ্যাপের থিম অ্যাট্রিবিউট অনুযায়ী মিডিয়া কোয়েরি prefers-color-scheme সেট করে, isLightTheme। অন্যভাবে বলতে গেলে, isLightTheme যদি true হয় বা উল্লেখ করা না থাকে, তাহলে prefers-color-scheme হল light; অন্যথায়, এটি হল dark। এই আচরণের অর্থ হল, কন্টেন্ট যদি এটি সাপোর্ট করে, তাহলে অ্যাপের থিমের সাথে ম্যাচ করার জন্য ওয়েব কন্টেন্টের লাইট বা ডার্ক স্টাইল অটোমেটিক প্রয়োগ করা হয়।

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

আপনি যদি এখনও আপনার অ্যাপের রঙের থিমের আচরণ কাস্টমাইজ করতে চান, তাহলে পরিবর্তে setAlgorithmicDarkeningAllowed() পদ্ধতি ব্যবহার করুন। Android-এর আগের ভার্সনের সাথে ব্যাকওয়ার্ড কম্প্যাটিবিলিটির জন্য, আমরা AndroidX-এ সমতুল্য setAlgorithmicDarkeningAllowed() পদ্ধতি ব্যবহার করার সাজেশন দিই।

আপনার অ্যাপের targetSdkVersion এবং থিম সেটিংসের উপর নির্ভর করে আপনার অ্যাপে আপনি কী ধরনের আচরণ আশা করতে পারেন সে সম্পর্কে আরও জানতে সেই পদ্ধতির ডকুমেন্টেশন দেখুন।

কানেক্টিভিটি

BluetoothAdapter#enable() এবং BluetoothAdapter#disable() বন্ধ করা হয়েছে

Android 13 (API লেভেল ৩৩) বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপের ক্ষেত্রে, BluetoothAdapter#enable() এবং BluetoothAdapter#disable() পদ্ধতি বন্ধ করা হয়েছে এবং সবসময় false রিটার্ন করে।

নিম্নলিখিত ধরনের অ্যাপ এই পরিবর্তন থেকে অব্যাহতি পেয়েছে:

• ডিভাইস মালিকের অ্যাপ
• প্রোফাইল মালিকের অ্যাপ
• সিস্টেম অ্যাপ

Google Play পরিষেবা

বিজ্ঞাপন আইডির জন্য অনুমতি প্রয়োজন

যেসব অ্যাপ Google Play পরিষেবা বিজ্ঞাপন আইডি ব্যবহার করে এবং Android 13 (API লেভেল 33) ও তার পরবর্তী ভার্সনকে টার্গেট করে, সেগুলিকে অ্যাপের ম্যানিফেস্ট ফাইলে AD_ID সাধারণ অনুমতি ঘোষণা করতে হবে, যেমন:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

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

আপনার অ্যাপ যদি এমন SDK ব্যবহার করে যা লাইব্রেরির ম্যানিফেস্টে AD_ID অনুমতি ঘোষণা করে, তাহলে ডিফল্ট হিসেবে আপনার অ্যাপের ম্যানিফেস্ট ফাইলের সাথে অনুমতি মার্জ করা হয়। এই ক্ষেত্রে, আপনার অ্যাপের ম্যানিফেস্ট ফাইলে অনুমতি ঘোষণা করার প্রয়োজন নেই।

আরও জানতে, Play Console সহায়তায় বিজ্ঞাপন আইডি দেখুন।

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

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

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

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

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