আচরণের পরিবর্তন: Android 13 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপ

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

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

গোপনীয়তা

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

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

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

অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে, ব্যবহারকারীকে আপনার অ্যাপটিকে বেশ কয়েকটি সাধারণ Wi-Fi ব্যবহারের ক্ষেত্রে ACCESS_FINE_LOCATION অনুমতি দিতে হবে৷

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

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

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

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

দানাদার মিডিয়া অনুমতি

ডায়ালগের জন্য 2টি বোতাম, উপরে থেকে নীচে, হল অনুমতি দিন এবং অনুমতি দেবেন না
চিত্র 1. সিস্টেম অনুমতি ডায়ালগ যা ব্যবহারকারী দেখতে পায় যখন আপনি READ_MEDIA_AUDIO অনুমতির অনুরোধ করেন।

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

মিডিয়ার ধরন অনুরোধ করার অনুমতি
ছবি এবং ফটো READ_MEDIA_IMAGES
ভিডিও READ_MEDIA_VIDEO
অডিও ফাইল READ_MEDIA_AUDIO

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

চিত্র 1 একটি অ্যাপ দেখায় যা 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 হার্ট রেট, তাপমাত্রা এবং রক্তের অক্সিজেন শতাংশের মতো শরীরের সেন্সরগুলির জন্য "ব্যবহারের সময়" অ্যাক্সেসের ধারণাটি প্রবর্তন করে। এই অ্যাক্সেস মডেলটি অ্যান্ড্রয়েড 10 (API স্তর 29) এ অবস্থানের জন্য সিস্টেমটি যেটি চালু করেছিল তার সাথে খুব মিল।

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

কর্মক্ষমতা এবং ব্যাটারি

ব্যাটারি সম্পদ ব্যবহার

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

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

PlaybackState থেকে প্রাপ্ত মিডিয়া নিয়ন্ত্রণ

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

চিত্র 2 যথাক্রমে একটি ফোন এবং ট্যাবলেট ডিভাইসে এটি কীভাবে দেখায় তার একটি উদাহরণ দেখায়।

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

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

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

স্লট অ্যাকশন মানদণ্ড
1 খেলা PlaybackState বর্তমান অবস্থা নিম্নলিখিতগুলির মধ্যে একটি:
  • STATE_NONE
  • STATE_STOPPED
  • STATE_PAUSED
  • STATE_ERROR
স্পিনার লোড হচ্ছে PlaybackState বর্তমান অবস্থা নিম্নলিখিতগুলির মধ্যে একটি:
  • STATE_CONNECTING
  • STATE_BUFFERING
বিরতি PlaybackState বর্তমান অবস্থা উপরের কোনটি নয়।
2 আগের PlaybackState অ্যাকশনের মধ্যে রয়েছে ACTION_SKIP_TO_PREVIOUS ।
কাস্টম PlaybackState অ্যাকশন ACTION_SKIP_TO_PREVIOUS অন্তর্ভুক্ত করে না এবং PlaybackState কাস্টম অ্যাকশনগুলি এমন একটি কাস্টম অ্যাকশন অন্তর্ভুক্ত করে যা এখনও স্থাপন করা হয়নি।
খালি PlaybackState অতিরিক্ত SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV কী এর জন্য একটি true বুলিয়ান মান অন্তর্ভুক্ত করে।
3 পরবর্তী PlaybackState অ্যাকশনের মধ্যে রয়েছে ACTION_SKIP_TO_NEXT ।
কাস্টম PlaybackState ক্রিয়াগুলি ACTION_SKIP_TO_NEXT অন্তর্ভুক্ত করে না এবং PlaybackState কাস্টম অ্যাকশনগুলি একটি কাস্টম অ্যাকশন অন্তর্ভুক্ত করে যা এখনও স্থাপন করা হয়নি৷
খালি PlaybackState অতিরিক্ত SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT কী-এর জন্য একটি true বুলিয়ান মান অন্তর্ভুক্ত করে।
4 কাস্টম PlaybackState কাস্টম অ্যাকশনগুলির মধ্যে একটি কাস্টম অ্যাকশন রয়েছে যা এখনও স্থাপন করা হয়নি।
5 কাস্টম PlaybackState কাস্টম অ্যাকশনগুলির মধ্যে একটি কাস্টম অ্যাকশন রয়েছে যা এখনও স্থাপন করা হয়নি।

কাস্টম অ্যাকশনগুলি PlaybackState -এ যে ক্রমে যুক্ত করা হয়েছিল সেই ক্রমে স্থাপন করা হয়৷

অ্যাপের রঙের থিম WebView সামগ্রীতে স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয়েছে

Android 13 (API লেভেল 33) বা উচ্চতর টার্গেট করা অ্যাপগুলির জন্য, setForceDark() পদ্ধতিটি অবমূল্যায়ন করা হয়েছে, যার ফলে পদ্ধতিটি কল করা হলে নো-অপ হবে৷

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

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

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

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

সংযোগ

BluetoothAdapter#enable() এবং BluetoothAdapter#disable() বঞ্চিত

অ্যান্ড্রয়েড 13 (API লেভেল 33) বা উচ্চতর টার্গেট করা অ্যাপগুলির জন্য, BluetoothAdapter#enable() এবং BluetoothAdapter#disable() পদ্ধতিগুলি বাতিল করা হয় এবং সর্বদা false ফেরত দেয়৷

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

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

গুগল প্লে পরিষেবা

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

যে অ্যাপগুলি 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>

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

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

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

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

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

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

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

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