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

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

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

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

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

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

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

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

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

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

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

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

ব্যাকগ্রাউন্ড অডিও দৃশ্যপট যা প্রভাব ফেলতে পারে

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

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

প্রভাব কমানোর জন্য সেরা ব্যাকগ্রাউন্ড অডিও অনুশীলন

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

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

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

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

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

• ১০ মিনিটের কম সময়ের ক্ষণস্থায়ী ব্যর্থতার সময় mediaPlayback FGS সক্রিয় রাখুন।

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

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

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

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

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

Android 16 এবং Android 17-এ পরিবর্তনগুলি পরীক্ষা করা হচ্ছে

এই বৈশিষ্ট্যটি ইতিমধ্যেই অ্যান্ড্রয়েড ১৬ থেকে "সতর্কতা" স্তরে বাস্তবায়িত হয়েছে। এর অর্থ হল অ্যাপগুলি ব্যাকগ্রাউন্ড অডিও হার্ডেনিং এনফোর্সমেন্ট ম্যানুয়ালি পরীক্ষা করার জন্য adb shell cmd audio set-enable-hardening ব্যবহার করতে পারে।

অ্যান্ড্রয়েড ১৬ চলমান ডিভাইসগুলিতে এনফোর্সমেন্ট সক্ষম করতে, নিম্নলিখিত কমান্ডটি চালান:

adb shell cmd audio set-enable-hardening 1

অ্যান্ড্রয়েড ১৭ চলমান ডিভাইসগুলিতে এনফোর্সমেন্ট অক্ষম করতে, নিম্নলিখিত কমান্ডটি চালান:

adb shell cmd audio set-enable-hardening 0

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

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

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

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

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

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

ব্যাকগ্রাউন্ড থেকে ফোরগ্রাউন্ড পরিষেবা শুরু করার বিধিনিষেধ বিভাগে আরও পড়ুন।

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