এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

পটভূমি অডিও শক্তকরণ

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

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

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

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

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

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

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

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

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

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

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

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

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

পটভূমি অডিওর এমন পরিস্থিতিগুলো যেগুলোর প্রভাব পড়ার সম্ভাবনা রয়েছে

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

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

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

ব্যাকগ্রাউন্ডে অডিও প্লেব্যাক পরিচালনা করতে মিডিয়া৩ জেটপ্যাক লাইব্রেরির MediaSessionService কম্পোনেন্টটি ব্যবহার করুন।
আপনি যদি তা করেন, তাহলে আপনার অ্যাপটি ব্যাকগ্রাউন্ড হার্ডেনিং দ্বারা প্রভাবিত হওয়ার সম্ভাবনা কম, কারণ লাইব্রেরিটি প্লেব্যাক লাইফসাইকেল পরিচালনায় সহায়তা করে।
আপনি যদি media3 লাইব্রেরি ব্যবহার না করেন, তাহলে আপনাকে ম্যানুয়ালি একটি mediaPlayback FGS চালু করতে হবে। ব্যাকগ্রাউন্ডে অডিও চলার সম্ভাবনা থাকলে, অ্যাপটি ফোরগ্রাউন্ডে থাকা অবস্থায় সর্বদা একটি ফোরগ্রাউন্ড সার্ভিস চালু করুন।
উদাহরণস্বরূপ, যদি আপনার অ্যাপটি একটি ভিডিও স্ট্রিমিং অ্যাপ হয় যা সাধারণত শুধুমাত্র ফোরগ্রাউন্ডে থাকে কিন্তু স্ক্রিন বন্ধ থাকা অবস্থাতেও প্লে হওয়া চালিয়ে যাওয়ার জন্য ব্যবহারকারীর সুবিধা থাকে, তাহলে যখন ব্যবহারকারীর দ্বারা প্লেব্যাক ট্রিগারটি ঘটে, তখনও আপনার অ্যাপটির একটি ফোরগ্রাউন্ড সার্ভিস চালু করা উচিত।
এটি করলে ফোরগ্রাউন্ড সার্ভিসটি WIU সক্ষমতা সহ চালু হয়।
১০ মিনিটের কম সময়ের ক্ষণস্থায়ী ত্রুটির সময় mediaPlayback এফজিএস সক্রিয় রাখুন।
যদি আপনার অ্যাপে কোনো সাময়িক ব্যর্থতা ঘটে, যেমন নেটওয়ার্ক কার্যকলাপের কারণে বাফারিং-এর সমস্যা, অথবা AUDIOFOCUS_LOSS_TRANSIENT মতো কোনো প্রত্যাশিত সাময়িক বাধা আসে, তাহলেও প্লে করার উদ্দেশ্যটি অব্যাহত থাকা উচিত। ফলে আপনার FGS সক্রিয় থাকা উচিত।
প্লেব্যাক শেষে ফোরগ্রাউন্ড সার্ভিসটি বন্ধ করুন এবং শুধুমাত্র ব্যবহারকারী স্পষ্টভাবে প্লেব্যাক পুনরায় শুরু করলেই তা পুনরায় চালু করুন।
প্লেব্যাক শেষ করার কোনো স্থায়ী সংকেতের ক্ষেত্রে (যেমন, কোনো অটো-প্লে ছাড়াই কন্টেন্ট সম্পূর্ণ হওয়া, একটি AUDIOFOCUS_LOSS , UMO থেকে একটি পজ ইভেন্ট, বা একটি মিডিয়া কী ইভেন্ট) অথবা কোনো অপূরণীয় ব্যর্থতার ক্ষেত্রে, আপনার অ্যাপের উচিত অডিও ইন্টারঅ্যাকশন বন্ধ করা, ফোরগ্রাউন্ড সার্ভিসটি থামানো এবং মিডিয়া সেশনটি শেষ করে দেওয়া। এই সবকিছু করাই হলো ব্যবহারকারীর কাছে কাঙ্ক্ষিত ব্যাকগ্রাউন্ড অডিও ইন্টারঅ্যাকশন "শেষ" করার ধারণা। এটি করার পর, আপনার অ্যাপের আর ব্যাকগ্রাউন্ড অডিও ইন্টারঅ্যাকশনের ক্ষমতা থাকে না।
পরবর্তীতে, যদি ব্যবহারকারী স্পষ্টভাবে প্লেব্যাক পুনরায় শুরু করেন, উদাহরণস্বরূপ আপনার অ্যাপের UI-এর মাধ্যমে বা ইউনিভার্সাল মিডিয়া অবজেক্টের প্লে বাটনের মাধ্যমে, তাহলে অডিও প্লেব্যাক শুরু করার ইন্টেন্টটি রিটার্ন করা উচিত, যার ফলে একটি নতুন FGS চালু হবে।
adb শেল কমান্ড ব্যবহার করে অডিও প্লেব্যাকের আচরণ পরীক্ষা করুন।

পরীক্ষার পরিবর্তন

অ্যান্ড্রয়েড ১৭ বা তার পরবর্তী সংস্করণে (বিটা ৩ থেকে শুরু করে) চালিত অ্যাপগুলিতে নিম্নলিখিত ADB কমান্ডটি চালিয়ে আপনি আপনার অ্যাপের সামঞ্জস্যতা পরীক্ষা করতে পারেন:

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

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

enable : সমস্ত অ্যাপের জন্য সকল অডিও হার্ডেনিং সীমাবদ্ধতা সক্রিয় করে। কোনো অ্যাপ অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) টার্গেট করুক বা না করুক, WIU ফোরগ্রাউন্ড সার্ভিসের আবশ্যকতাটি প্রযোজ্য হয়। এছাড়াও, অ্যাপটি যদি অ্যালার্ম স্ট্রিমে পরিবর্তন করে এবং তার সঠিক অ্যালার্ম পারমিশন থাকে, তাহলেও এই আবশ্যকতাটি বলবৎ করা হয়।
disable : সমস্ত অডিও হার্ডেনিং বিধিনিষেধ নিষ্ক্রিয় করে।
throw : সমস্ত অ্যাপের জন্য সমস্ত অডিও হার্ডেনিং সীমাবদ্ধতা সক্রিয় করে, যেমন enable । এছাড়াও, এই ফ্ল্যাগটি ভলিউম এবং ফোকাস ইন্টারঅ্যাকশনের জন্য IllegalStateException থ্রো করে উচ্চস্বরের ব্যর্থতা সক্রিয় করে। অডিও প্লেব্যাকের জন্য, write মেথডটি ক্রমাগত একটি এরর কোড রিটার্ন করে। সুস্পষ্ট write ছাড়া প্লেব্যাক মোডগুলির জন্য, অ্যাপটি ক্র্যাশ করে।

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

ব্যবহারকালীন সক্ষমতা সহ FGS বোঝা

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

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

এখানে একটি দরকারি তথ্যসূত্র দেওয়া হলো:

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

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

প্রভাবিত অডিও এপিআইগুলির সম্পূর্ণ তালিকা

অডিও ফাংশন	ফলাফল	প্রভাবিত এপিআই
অডিও প্লেব্যাক	প্লেব্যাক নীরব করা হয়েছে কোনো ব্যতিক্রম নেই, কোনো API দ্বারা কোনো ব্যর্থতার বার্তা প্রদান করা হয়নি।	`AudioTrack.write()` (এনডিকে) `AAudioStream_write` অ্যান্ড্রয়েডের জন্য ওপেনএসএল ইএস ক্লায়েন্ট সাইডের যে সকল মিডিয়া লাইব্রেরি প্লেব্যাক পরিচালনা করে, যেমন media3, Exoplayer এবং Oboe, সেগুলোও প্রভাবিত হতে পারে।
অডিও ফোকাস অনুরোধ	`AUDIOFOCUS_REQUEST_FAILED` ফেরত দেয় অন্যান্য অ্যাপের অডিও প্লেব্যাকে কোনো প্রভাব পড়ে না, কোনো ফোকাস অর্জিত হয় না।	`AudioManager.requestAudioFocus()`
ভলিউম এবং রিংগার মোড এপিআই	রিংগার মোড বা ভলিউমের উপর কোনো প্রভাব পড়ে না (মেথড কল নীরবে উপেক্ষা করা হয়)। কোনো ব্যতিক্রম নেই, কোনো API দ্বারা কোনো ব্যর্থতার বার্তা প্রদান করা হয়নি।	`AudioManager.setStreamVolume()` `AudioManager.setStreamMute()` `AudioManager.adjustStreamVolume()` `AudioManager.adjustVolume()` `AudioManager.adjustSuggestedStreamVolume()` `AudioManager.setRingerMode()`