ব্যাকগ্রাউন্ড অডিও হার্ডেনিং

Android ১৭ থেকে, অডিও ফ্রেমওয়ার্ক ব্যাকগ্রাউন্ড অডিও ইন্টার‍্যাকশনের উপর বিধিনিষেধ আরোপ করে, যার মধ্যে অডিও প্লেব্যাক, অডিও ফোকাস অনুরোধ এবং ভলিউম পরিবর্তন API অন্তর্ভুক্ত, যাতে এইসব পরিবর্তন ব্যবহারকারী ইচ্ছাকৃতভাবে শুরু করেছেন কিনা তা নিশ্চিত করা যায়।

Android 17-এ রান করা যেসব অ্যাপে এই ধরনের ব্যাকগ্রাউন্ড অডিও ইন্টার‍্যাকশন আছে, সেগুলিতে অবশ্যই দৃশ্যমান অ্যাক্টিভিটি থাকতে হবে অথবা সেগুলিকে অবশ্যই এমন ফোরগ্রাউন্ড সার্ভিস রান করতে হবে যা SHORT_SERVICE ধরনের নয়। অ্যাপটি API লেভেল ৩৭ টার্গেট করুক বা না করুক, এটি প্রযোজ্য।

কোনও অ্যাপ Android 17 (API লেভেল 37) টার্গেট করলে, অতিরিক্ত বিধিনিষেধ প্রযোজ্য হয়। অ্যাপটি ব্যাকগ্রাউন্ডে চললে, অ্যাপটিকে অবশ্যই একটি ফোরগ্রাউন্ড পরিষেবা চালাতে হবে যার ব্যবহার-চলাকালীন (WIU) ক্ষমতা আছে। (কোনও ফোরগ্রাউন্ড সার্ভিসকে WIU ক্ষমতা প্রদান করা হয় যদি এটি ব্যবহারকারীর শুরু করা কোনও অপারেশনের উত্তরে বা অ্যাপটি ব্যবহারকারীর কাছে দৃশ্যমান থাকাকালীন শুরু করা হয়।) তবে, অ্যাপকে এক্স্যাক্ট অ্যালার্ম সংক্রান্ত অনুমতি দেওয়া হলে, WIU ক্ষমতার প্রয়োজনীয়তা মকুব করা হয় এবং এটি USAGE_ALARM অ্যাট্রিবিউট আছে এমন অডিও স্ট্রিমে পরিবর্তন করে।

অ্যাপটি সঠিক লাইফসাইকেলে না থাকা অবস্থায় অডিও API কল করার চেষ্টা করলে, অডিও প্লেব্যাক এবং ভলিউম পরিবর্তন API কোনও ব্যতিক্রম না দেখিয়ে বা ব্যর্থতার মেসেজ না দিয়ে নীরবে ব্যর্থ হয়। অডিও ফোকাস API, AUDIOFOCUS_REQUEST_FAILED ফলাফল কোড সহ ব্যর্থ হয়েছে।

আমরা কেন এই পরিবর্তন করছি

এইসব বিধিনিষেধ আরোপ করার উদ্দেশ্য হল অনিচ্ছাকৃত ব্যাকগ্রাউন্ড অডিও সংক্রান্ত সমস্যা কমানো। কিছু উদাহরণ হল:

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

আমরা ডেভেলপারদের তাদের অ্যাপ পরীক্ষা করতে এবং আচরণের পরিবর্তন সম্পর্কে মতামত প্রদান করতে উৎসাহিত করি যদি ইচ্ছাকৃতভাবে অডিও ব্যবহারের কোনও ক্ষেত্রে নেতিবাচক প্রভাব পড়ে। এই Android 17 অ্যাপ কম্প্যাট সমস্যা ট্র্যাকার ব্যবহার করে যেকোনও সমস্যার ব্যাপারে অভিযোগ জানান।

প্রভাবিত ব্যাকগ্রাউন্ড অডিও ব্যবহারের ক্ষেত্র শনাক্ত করুন

আপনার অডিও প্লেব্যাক ইমপ্লিমেন্টেশন অডিট করুন এবং আপনার অ্যাপের উদ্দেশ্য ব্যাকগ্রাউন্ড অডিও ইন্টার‍্যাকশন ফাংশনালিটি প্রদান করা কিনা তা শনাক্ত করুন, এমনকি শর্তসাপেক্ষ পরিস্থিতিতেও।

আপনার অ্যাপ যদি শুধুমাত্র অডিও চালাতে চায় বা অডিও API ব্যবহার করতে চায়, যখন এটি ব্যবহারকারীর কাছে দৃশ্যমান কোনও অ্যাক্টিভিটি দেখায়, যার মধ্যে ছবির-মধ্যে-ছবি (PiP) মোড ব্যবহার করাও অন্তর্ভুক্ত, তাহলে এই পরিবর্তনগুলির কোনওটির দ্বারা এটি প্রভাবিত হবে না।

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

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

ব্যাকগ্রাউন্ড অডিও সংক্রান্ত পরিস্থিতি যাতে প্রভাব পড়তে পারে

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

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

প্রভাব কমানোর জন্য ব্যাকগ্রাউন্ড অডিও সংক্রান্ত পেশাদার পদ্ধতি

  • ব্যাকগ্রাউন্ড অডিও প্লেব্যাক ম্যানেজ করতে media3 জেটপ্যাক লাইব্রেরির MediaSessionService কম্পোনেন্ট ব্যবহার করুন।

    আপনি এটি করলে, ব্যাকগ্রাউন্ড হার্ডেনিংয়ের কারণে আপনার অ্যাপ প্রভাবিত হওয়ার সম্ভাবনা কম, কারণ লাইব্রেরি প্লেব্যাক লাইফসাইকেল ম্যানেজ করতে সাহায্য করে।

  • আপনি media3 লাইব্রেরি ব্যবহার না করলে, আপনাকে ম্যানুয়ালি mediaPlayback FGS শুরু করতে হবে। ব্যাকগ্রাউন্ড অডিও চালু থাকলে, অ্যাপ ফোরগ্রাউন্ডে থাকাকালীন সবসময় ফোরগ্রাউন্ড সার্ভিস চালু করুন।

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

    এটি করলে, ফোরগ্রাউন্ড পরিষেবা WIU ক্ষমতার সাথে চালু হয়েছে কিনা তা নিশ্চিত করা যায়।

  • ১০ মিনিটের কম সময়ের জন্য হওয়া ট্রানজিয়েন্ট ব্যর্থতার সময় mediaPlayback FGS অ্যাক্টিভ রাখুন।

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

  • প্লেব্যাক শেষ হওয়ার পরে ফোরগ্রাউন্ড সার্ভিস বন্ধ করুন এবং ব্যবহারকারী স্পষ্টভাবে প্লেব্যাক আবার চালু করলে তবেই প্লেব্যাক আবার চালু করুন।

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

    পরবর্তীকালে, ব্যবহারকারী যদি স্পষ্টভাবে প্লেব্যাক আবার চালু করেন, যেমন আপনার অ্যাপের UI বা ইউনিভার্সাল মিডিয়া অবজেক্ট প্লে বোতামের মাধ্যমে, তাহলে অডিও প্লেব্যাক চালু করার ইনটেন্ট ফিরিয়ে আনতে হবে, যার ফলে নতুন করে FGS চালু হবে।

  • adb শেল কমান্ডের মাধ্যমে অডিও প্লেব্যাক আচরণ পরীক্ষা করুন।

পরিবর্তন পরীক্ষা করা হচ্ছে

আপনি Android 17 বা তার পরবর্তী ভার্সনে (Beta 3 থেকে শুরু করে) চলা অ্যাপে আপনার অ্যাপের সম্মতি পরীক্ষা করতে পারেন নিম্নলিখিত ADB কমান্ড রান করে:

adb shell cmd audio set-enable-hardening <enable|disable|throw>

এই কমান্ডে নিম্নলিখিত বিকল্পগুলি রয়েছে:

  • enable: সব অ্যাপের জন্য সব অডিও হার্ডেনিং সংক্রান্ত বিধিনিষেধ চালু করে। কোনও অ্যাপ Android 17 (API লেভেল ৩৭) টার্গেট করুক বা না করুক, WIU ফোরগ্রাউন্ড সার্ভিসের জন্য প্রয়োজনীয়তা প্রযোজ্য হয়। এছাড়াও, অ্যাপটি অ্যালার্ম স্ট্রিমে পরিবর্তন করলেও এবং এক্স্যাক্ট অ্যালার্মের অনুমতি থাকলেও প্রয়োজনীয়তা এনফোর্স করা হয়।

  • disable: সমস্ত অডিও হার্ডেনিং বিধিনিষেধ বন্ধ করে দেয়।

  • throw: সব অ্যাপের জন্য সব অডিও হার্ডেনিং সংক্রান্ত বিধিনিষেধ চালু করে, যেমন enable. এছাড়াও, এই ফ্ল্যাগ লাউড ফেলিয়র চালু করে, ভলিউম ও ফোকাস ইন্টার‍্যাকশনের জন্য IllegalStateException থ্রো করে। অডিও প্লেব্যাকের জন্য, রাইট পদ্ধতি ক্রমাগত একটি ত্রুটি কোড ফেরত দেয়। স্পষ্টভাবে লেখা নেই এমন প্লেব্যাক মোডের জন্য, অ্যাপ ক্র্যাশ করে।

অডিও হার্ডেনিং এনফোর্সমেন্টের কারণে অ্যাপে কোনও সাইলেন্ট ব্যর্থতা হয়েছে কিনা তা শনাক্ত করতে adb dumpsys audio বা logcat ব্যবহার করুন। যদি তা হয়, তাহলে আপনার প্যাকেজের নামের আগে AudioHardening লেখা একটি এন্ট্রি থাকবে। মেসেজে level: full থাকলে, আপনার অ্যাপ ফোরগ্রাউন্ড সার্ভিস চালাচ্ছে, কিন্তু সার্ভিসটির ব্যবহার-চলাকালীন ক্ষমতা নেই। মেসেজে level: partial থাকলে, আপনার অ্যাপ ফোরগ্রাউন্ড সার্ভিস একেবারেই চালাচ্ছে না।

ব্যবহার করার সময় কাজ করার ক্ষমতা সহ FGS বোঝা

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

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

এখানে একটি সহজ রেফারেন্স দেওয়া হল:

  • স্ট্যান্ডার্ড FGS: অ্যাপ দৃশ্যমান থাকাকালীন বা ব্যাকগ্রাউন্ড অ্যাক্টিভিটি লঞ্চ করার ক্ষমতা মঞ্জুর করা হলে, পরিষেবা শুরু হয় এবং WIU অ্যাক্সেস মঞ্জুর করা হয়।
  • ব্যাকগ্রাউন্ডে-চালু হওয়া FGS (BFSL): বেশিরভাগই WIU অ্যাক্সেস দেয় না। প্রাথমিক ব্যতিক্রম যা WIU মঞ্জুর করে তা হল ব্যবহারকারীর স্পষ্ট উদ্দেশ্য সহ ইন্টার‍্যাকশন, যেমন, বিজ্ঞপ্তিতে ক্লিক, উইজেট ইন্টার‍্যাকশন বা এক্সটার্নাল ডিভাইস থেকে মিডিয়া কী ইভেন্ট।
  • সিস্টেম FGS চালু করেছে: ফোরগ্রাউন্ড পরিষেবাগুলিকে WIU অ্যাক্সেস দেওয়া হয় যদি সেগুলি সিস্টেম-সার্ভার ডেলিগেশন দ্বারা শুরু করা হয় (যেমন, টেলিকম জেটপ্যাক লাইব্রেরি থেকে), বা সিস্টেম বাইন্ডিং দ্বারা যা একটি উন্নত ফোরগ্রাউন্ড স্টেটকে প্রতিনিধিত্ব করে ডেডিকেটেড কার্যকারিতা সম্পাদন করতে (যেমন একটির জন্য VoiceInteractionService)।

ব্যাকগ্রাউন্ড থেকে ফোরগ্রাউন্ড পরিষেবা চালু করার ক্ষেত্রে বিধিনিষেধ সম্পর্কে আরও পড়ুন।

প্রভাবিত হওয়া অডিও API-এর সম্পূর্ণ তালিকা

অডিও ফাংশন

ফলাফল

প্রভাবিত API

অডিও প্লেব্যাক

প্লেব্যাক সাইলেন্ট করা আছে

কোনও ব্যতিক্রম নেই, কোনও API-এর মাধ্যমে ব্যর্থতার মেসেজ প্রদান করা হয়নি

AudioTrack.write()

(NDK) AAudioStream_write

Android-এর জন্য OpenSL ES

এছাড়াও, media3, Exoplayer ও Oboe-এর মতো প্লেব্যাক ম্যানেজ করে এমন যেকোনও ক্লায়েন্ট সাইড মিডিয়া লাইব্রেরি প্রভাবিত হতে পারে।

অডিও ফোকাস করার অনুরোধ

AUDIOFOCUS_REQUEST_FAILED ফেরত দেওয়া

অন্যান্য অ্যাপের অডিও প্লেব্যাকের উপর কোনও প্রভাব নেই, কোনও ফোকাস অর্জন করা হয়নি

AudioManager.requestAudioFocus()

ভলিউম ও রিঙ্গার মোড API

রিঙ্গার মোড বা ভলিউমে কোনও প্রভাব নেই (মেথড কল সাইলেন্টলি উপেক্ষা করা হয়)

কোনও ব্যতিক্রম নেই, কোনও API-এর মাধ্যমে ব্যর্থতার মেসেজ প্রদান করা হয়নি

AudioManager.setStreamVolume()

AudioManager.setStreamMute()

AudioManager.adjustStreamVolume()

AudioManager.adjustVolume()

AudioManager.adjustSuggestedStreamVolume()

AudioManager.setRingerMode()